High Priority:

 * Restore serialisation of state between upstart processes.  Having made
   the structures in memory more sane, this should be easier again, as
   long as we send things in this order:

    * EventEmission queue
    * Job hash (referencing cause and blocked events by id, also need to
      ensure we handle instance jobs proeprly)
    * NotifySubscription list (which references both events by id and jobs
      by name [or id])
   
   I want to use the IPC protocol for this, since it's somewhat stable
   now.  Handing off will still use the "fork a child, exec in the parent"
   model, except for the following.

    * Leave the control socket open, clear the cloexec flag, and pass its
      file descriptor number to the new init process.
    * In the child, close the control socket we had open and open an
      ordinary socket; blocking-write the information to that and then die.


Medium Priority:

 * EventEmission records need to hang around longer, since that's the source
   of environment variables, etc.  We should only clear the cause when we
   change the goal; otherwise we should just decrease the job count (while
   maintaining a reference count).  This means events can be finished, but
   still referenced. -- should also be freed when we reach "stop"

 * Iterating through every Job's start and stop events is messy; we should
   have some kind of match lookup table to make it easier.

 * Likewise iterating through all the Jobs to find a pid is messy; we
   should have a lookup table for these too.

 * When spawning a process, keep a pipe open (but mark it FD_CLOEXEC); if
   we encounter any problems write the error code to this pipe and die.
   Then from above, we can read this pipe to determine whether the job
   failed before or after the exec.  (Might be a cleaner way to do this).


Low Priority:

 * If environment variables don't have an = in them, copy that variable
   from init's environment (default PATH, TERM).  On the subject of
   process_setup_environment, it's getty very messy; it's about time it
   got cleaned up -- and maybe don't use putenv/setenv since they're a
   little strange.

 * Need to add dependencies to jobs, which are files that must exist before
   the job can be started (because Debian/Ubuntu like to litter config files
   like jobs)

 * process_setup_console is due for an overhaul as well; especially if
   we want to be able to pass file descriptors in.  Am somewhat tempted
   to add a magic CONSOLE_DEFAULT option which tries fd, logging, null,
   etc.  and use CONSOLE_LOGGED to mean "die if logd isn't around".

 * We always want /dev/fd/NNN to be /dev/fd/3, we should have some way
   to instruct process_spawn to do that.

 * We may need to KILL scripts, e.g. post-start; especially when the goal
   changes.  Or perhaps just after a timeout?

 * May need a way to force ignoring of the KILL signal, and assuming that
   a job that won't die really has.

 * Should be possible to configure things in one file, definings jobs with
   a stanza rather than separate files.

 * Replace logd raise/wait/kill interlock with a pipe-based one?

 * Replace logd with something else that's more standard in the system,
   and just use a normal API to communicate with it.

 * logd is currently disabled because of the problem where it goes away,
   and the scripts being run end up vanishing because they can't write
   data.


Unfinished Features:

 * Handle locating the pid for a spawned daemon, use an inotify watch
   on the pid file or scan /proc.

 * Get the LANG environment variable somehow.


Future Features:

 * Per-user services; will need to use PAM to set up the session.
   We want to do this for "root-user services" but not for jobs/tasks

 * Passing of environment and file descriptors from event over control
   socket.

 * Register services over the control socket.

 * Temporal events ("15m after startup")

 * Scheduled times ("every day at 3:00")

 * Load average checking, maybe have separate CPU, Network and I/O
   stats?

 * Actions: "reload" and optional replacements for "stop", "start", etc.

   This is mostly just a matter of deciding policy for when they can be run,
   and adding "user processes" onto the end of the job->process array.

 * Alternative script interpreters; "start script python".

   Would be done by making script a char *, and putting the interpreter into
   command?

 * Resources, "uses cpu 1.0" -- where cpu has a defined max (default 1.0);
   which state do we keep it in while it's waiting?

 * Apply event variables to keys, such as "uses" and "stop on"

 * Watershed jobs (this actually might apply to events, since you might
   want to try starting again if a particular event has come in since you
   were last started)

 * How do we balance events, if two "added" happen we probably want two
   "removed" to happen as well.  One way is to allow $... in the event
   definitions which apply to earlier ones?

 * Extend telinit to support --default or similar; moving the shell parsing
   out of rc-default and just make that exec telinit with the right args.

 * Event tree for "start on" and "stop on" -- need to solve when instances
   are spawned and which event gets stored in cause first though.

 * Instance names, appended to a running job's title and set in the job
   definition using a variable from an event?
