`Empty' job files?

[Scott James Remnant]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20081101/668421a0/attachment.pgp