Hey Ludo,

On Fri, Feb 09 2018, Ludovic Courtès wrote:
In particular, with higher levels of concurrency I want to move the
mutable state out of <service> objects.


The only piece of mutable state is the ‘running’ value. We can make
that an “atomic box”, and users won’t even notice.

That's not quite true, unfortunately. I count four pieces of mutable state in the <service> object: `running`, `enabled?`, `waiting-for-termination?` and `last-respawns`. They should be stored elsewhere so that Shepherd can manage that state however it wants. We don't want to expose that to a user, where they could break Shepherd's assumptions about when/how it's modified (because user configuration can do anything it wants - including starting a long-running thread to mutate it later).

We shouldn't have to break much. My thought is just to remove those mutable fields from the <service> object (maybe leaving `enabled?`, but changing its meaning slightly to just be whether the service is enabled at the start). In practice it shouldn't break any real-world configuration, I hope.

Carlo

Attachment: signature.asc
Description: PGP signature

Reply via email to