Dependencies

[Jerry Haltom]

> events have come in onto the scripts, which are stateless.  It is much less 
> effort for the init process -- which IS stateful -- to keep track of these 
> events than it is for the scripts.  Not only are you making it harder to 
> write such scripts by offloading that work onto the scripts, but EVERY script 
> will have to deal with state, meaning much duplicate code.  On top of this, 
> it could become quite expensive.

Sure. But when do you CLEAR it? Job maintains a list of... all waited
for events? When the list is all checked off it runs? When do you clear
this list? You need to check ANYWAYS. You shouldn't just rely on some
random event string appearing to guarantee that something is in a given
state. What if somebody mounts and then unmounts a filesystem really
fast? You start operating on the "mount" event when the system is
already unmounted. All the scripts which deal with this stuff are going
to have to properly check conditions before they execute anyways.

I think a lot of this logic can actually be stored in the body of the
job itself. Read below.

> Consider the case where some script needs three or four events to have come 
> in, and checking for the state of each event can take several hundred 
> milliseconds (say, one has to do an arping, one has to query the USB bus, one 
> has to look for a PCMCIA card).  Each time one of these events comes in, ALL 
> states have to be checked for.  I don't believe that this is a wild edge 
> case.  If the init process keeps track of the events that it has delivered, 
> then it is much more efficient and easier to write scripts.

Countered above, I believe. Still, when all 4 events are received in
full, all 4 conditions still need to be checked right then.

> The simple implementation wouldn't affect the complexity of the scripts, or 
> drastically affect the complexity of the init process.  A more complex 
> implementation would have mechanisms for allowing scripts to perform checks 
> on each type of event, returning true (partial satisfaction of start/stop 
> conditions, so init considers that event requirement met) or false (does not 
> satisfy start/stop condition, so init leaves the event requirement in the 
> queue).  I'm not sure that this level of complexity is necessary -- I'm only 
> peripherally thinking about the sorts of problems that it would address.  But 
> it seems obvious that scripts requiring multiple events to occur before they 
> can start will be -- and are -- common.

I think with some reusable and smart shell scripts, each job can take
care of that, without much overhead.

start on event1
start on event2
start on event3

script
   source /usr/share/upstart/functions
   upstart_waitfor event1 event2 event3
   # check conditions, do stuff.
end script

In this example, waitfor waits for all of event1, event2 and event3 to
arrive. It creates a variable to track progress, adds UPSTART_EVENT (the
initiating event) to it, and opens a socket to upstart to track the
rest.

Basically, while waiting, it results in a sh instance sitting around
blocking on a socket. Not exactly much overhead. "waitfor" could timeout
and fail if it wanted to, too.

I just made this idea up right now, btw. Not sure if that's a good idea
at all. I do like the way it's isolated to the job code though.

> 
> I'm sure you've thought about all this, so I'd be interested to hear the 
> reasoning for having the scripts track the system state.
> 
> > > Also, I'd like a pointer to any discussion about conditional use cases. 
> ...
> > Cups is a hard one. I'd say it should either watch the network on it's
> 
> Well, Cups was just an example.  The Gentoo init scripts are full of examples 
> of services which have conditional requirements.  The idea is that there's a 
> mechanism for saying "if this service is going to be started, then wait for 
> it to start.  Otherwise, just start now."

I'm not sure if we've addressed this, except to propose a "before"
argument to a job. Basically just orders the jobs an event will effect.
Could actually be done the same way. Both jobs are started equally by
upstart, one job waits for the other to be started before finishing.

> 
> > A lot of those features barely even exist. I think the best we've got
> > about where we're going is a wiki page:
> > https://wiki.ubuntu.com/UpstartDesignChanges
> 
> Oh, OK.  I thought I had read something about Upstart already supporting 
> multiple event prerequisites... but I can't find the page now, and I may have 
> simply misunderstood the feature that services can register to listen for 
> multiple events.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20061008/35ffc367/attachment.pgp