Implementing a state machine in upstart (0.5)

[Kees Jongenburger]

Hi replying to myself...

On Fri, Jan 30, 2009 at 12:13 PM, Kees Jongenburger
<kees.jongenburger at gmail.com> wrote:
> I am facing the following problems:
>
> My change handler is defined to "start on event_a or event_b......"
> the problem with that is that if an event is generated
> while the change_handler is running upstart simply skips starting my
> change_handler and I miss event. I think that because it's already
> running but I am not sure
> To keep my state machine in a consistent state I can only run a single
> instance of the handler but still want to get all the events is that
> possible?
This was not possible. Even when using the start on event_a and stop on event_a
hack events go missing.

>
> I noticed  that the  "on bounce" behavior found in
> http://upstart.ubuntu.com/getting-started.html was not working
> would emitting 5 bounces create 5 instances or run 5 time the talks
> one after the other?
It would be nice to get an answer for a developer on this basic question.
>


Based on the problem we had (missing events) we made the following
functional changes to upstart:

When a start event is supposed to start a "task" but the event is
already running we queue the event
until the job is stopped. only after that we relaunch the event. We do
this only for tasks (not services).
Would such behavior be wanted in upstart?


The implementation was done as follow:
in event_pending_handle_jobs (in event.c) when we receive a start job
and this job already exists
we block the event using event_block (event) and keep a ref to the
event in the job.
Upon job completions we iterate over the events we are blocking and
booth unblock and reset them to  EVENT_PENDING
This results a a simple queuing mechanism that also keeps the right
order of the events.

Greetings