Upstart 1.0 Design discussion

[Scott James Remnant]

On Sat, 2009-09-12 at 19:03 -0400, Casey Dahlin wrote:

> On 09/12/2009 12:31 PM, Scott James Remnant wrote:
> > Another interesting thing abouts events is that they too have a
> > lifecycle and different states.
> >
> > They're not just fired and forgotten: the event is kept "open" all the
> > time that jobs that it changed are in transition between levels.  Only
> > once the jobs are all back at a rest level again is the event finished.
> >
> 
> My earlier email on Triggers proposes doing away with this internally. 
> Events are now fire-and-forget.
> 
I'm not sure what you mean here, do you mean that you're removing the
blocking behaviour of events entirely?

I've tried to describe what the external interface would look like,
rather than necessarily an internal implementation.  It's possible to
implement events with "finished" logic in about a thousand different
ways.

I do think that it's important that:

 1. events are fired off once, and affect all jobs in one atomic
    operation

 2. once those jobs all reach a rest state, the event is "finished" and
    this is notified back to the emitter of an event

 3. and thus, consequently, events can be "failed" if jobs fail to
    start/stop as a result

If you don't think they should behave like this, we should talk about
that first before discussion about implementation.

> Previously the logic was:
> 1) A job changes goal, and fires a "starting" event.
> 2) The job waits for the starting event to unblock.
> 3) The job continues.
> 
> The new logic is:
> 1) A job changes goal and fires a starting event.
> 2) The job stops in place.
> 3) The fired event sets up a series of handlers that will cause the job 
> to begin moving again when all of the responders have answered.
> 
Well, this is confusing because the job doesn't "wait" for the starting
event to unblock - it simply exists the job_change_state() loop.  It's
up to event_unblock() to call job_change_state() again to continue the
state transition.

The only difference between this and your logic, I guess, is that the
call is hardcoded rather than using a function pointer.

> Is this a good idea? My code will be the proof :) Outwardly scary as the 
> idea of these "fire, tell someone else, and forget" events is, it has 
> drastically simplified the code it has touched (EventOperator itself 
> will soon entirely evaporate from my branch).
> 
I want to make sure we preserve the behaviour of event operator though.
There's some wonderful emergent behaviour from it.

For example, here's how to block starting of the display manager until
another service has actually stopped:

	start on stopped mountall and starting gdm
	task

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20090914/880e9fa0/attachment-0001.pgp