Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Upstart is currently a largely parallel system, serialisation is only provided within a single job; it is not possible for one job to delay the starting or stopping of another until it has completed itself. This specification proposes allowing serialisation by waiting for the completion of events before moving on to the next state.

Rationale

While researching example jobs, it became apparent that there are two common pairing of job events that other jobs will be using. Jobs that depend on another will be started on the started event, because they need it to be running, and will therefore be stopped on the stopping event. The other major kind of jobs are those that believe the other job depends on them; they'll be started on the other's starting event so that they can be running by the time the other is started, and will be stopped by the other's stopped event because they want to be around if there's any possibility the other job is around.

For the first kind of job, we'll almost always want it to be stopped before the job it depends on is allowed to stop. For the second, we'll amost want it to be started before the job that is a dependency on is allowed to start.

While this can be done within the pre-start or pre-stop tasks, e.g. by waiting for initctl emit to complete; it's going to be sufficiently common that it's worth upstart handling this by default.

Use cases

Scope

This scope of this specification is limited to the changes necessary to allow for serialisation of jobs.

Design

Implementation

Code

Instead of job_change_state in init/job.c starting the process directly when entering the starting or stopping states, only the event will be emitted. The job will be in the appropriate state, but with no process running.

Once handling of the event completes, the process will actually be started.

Data preservation and migration

These changes are being made to features that do not yet exist, so while they are not backwards compatible with those features as specified, these should not present a problem.


CategorySpec

JobSerialisation (last edited 2011-08-26 04:10:18 by localhost)