Hello Guix! I recently pushed a Shepherd branch called ‘wip-service-monitor’:
https://git.savannah.gnu.org/cgit/shepherd.git/log/?h=wip-service-monitor It creates a “service monitoring agent”—code that runs in a separate fiber and encapsulates the current state of services: registered, running, etc. Currently, state is managed directly within <service> objects, for instance with the ‘running’ slot; this approach would replace that. The expected benefits are: improved clarity through separation of state from config, and finer-grain view of service state. The first visible application (and original motivation) is a representation of services that are “being started”. Currently, we can only distinguish between “running” and “stopped” services; the monitoring agent has been augmented to handle a “starting” state. It provides a synchronization mechanism that makes sure that (start S) blocks until S has been started, in case it was already being started (that’s the semantics we had pre-0.9 but 0.9 broke that.) The service monitor is a fiber that answers requests on a dedicated channel, similar to a client/server model with remote procedure calls (RPCs). That way, all accesses to service state are serialized. At this point, there’s still state in <service>, such as respawn times, that we could move to the monitor. Feedback welcome! Ludo’.
