Why Cotyledon

This library is mainly used in OpenStack Telemetry projects, in replacement of
oslo.service. However, as oslo.service depends on eventlet, a different
library was needed for project that do not need it. When an application do not
monkeypatch the Python standard library anymore, greenlets do not in timely
fashion. That made other libraries such as Tooz or oslo.messaging to fail with e.g. their
heartbeat systems. Also, processes would not exist as expected due to
greenpipes never being processed.

oslo.service is actually written on top of eventlet to provide two main
features:

periodic tasks

workers processes management

The first feature was replaced by another library called futurist and the second feature is
superseded by Cotyledon.

Unlike oslo.service, Cotyledon have:

The same code path when workers=1 and workers>=2

Reload API (on SIGHUP) hooks work in case of you don’t want to restarting children

A separated API for children process termination and for master process termination

Seatbelt to ensure only one service workers manager run at a time.

Is signal concurrency safe.

Support non posix platform, because it’s built on top of multiprocessing module
instead of os.fork

Provide functional testing

And doesn’t:

facilitate the creation of wsgi application (sockets sharing between parent
and children process). Because too many wsgi webserver already exists.

oslo.service being impossible to fix and bringing an heavy dependency on
eventlet, Cotyledon appeared.