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
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
