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