On Sat, Nov 1, 2008 at 9:56 AM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > On Wed, 2008-10-29 at 10:54 -0700, Garrett Cooper wrote: > >> Emitted signals are asynchronous, one-time items whereas having jobs >> act as states seems a bit heavy-handed for upstart, as the resources >> for the jobs stays locked into memory and with enough jobs can >> subsequently bog down upstart and prevent it from doing its purpose >> (monitoring jobs) well. >> > The overhead for a state is intended to be quite low; and since Upstart > will need to track many hundreds of them, it's something we'd like to > optimise as much as we can. > > Current intent for Upstart 0.10 separates the "state" and "job" parts of > the objects anyway. > > So this would be just a job: > > /etc/init/something: > exec /sbin/daemon > > You have to instantiate that manually, and stop it manually as well: > > # start something > something: no such job > > # start --new something > something: started > > This would be just a state: > > /etc/init/wibble: > while foo or bar > > It's automatically instantiated for each foo or bar instance that > exists, and those instances automatically clean themselves up. You > can't manually start or stop these. > > And this would combine both into a job that is automatically > instantiated by a state: > > /etc/init/ferrari: > while foo or bar > exec /sbin/daemon
But I can "start" a state though and it persistently runs, instead of finishing, or is the intention of the "empty job files" to be something of the flavor of a Mealy instead of Moore FSM? -Garrett -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
