xon/xoff, signals, hangup

[Chris Torek]

In article <2269 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>The basic problem here is that a process is only ever waiting on one
>event at a time. This is so fundamental to UNIX that you don't ever
>think about it... but there's really no reason why it has to be that
>way.

Select() and, in SVR?, poll(), wait on multiple events, although they
do it somewhat by cheating.

>Here's an idea that would get you around this problem: when you send a signal
>to a process, force a wakeup on whatever that process is waiting on. That
>should make it pay attention to the signal and go on to die.

Not necessarily; indeed, the usual wait loop is something like

	while (resource->flag & LOCKED) {
		resource->flag |= WANTED;
		sleep((caddr_t)resource, priority);
	}
	resource->flag |= LOCKED;

	<critical section code>

	if (resource->flag & WANTED)
		wakeup((caddr_t)resource);
	resource->flag &= ~(LOCKED|WANTED);

Since the locking code is a while loop, forcing a wakeup would have no
effect.

Fortunately, that is not how things work.  If the `priority' argument
to sleep() is greater than PZERO, a signal will force an exit by a
non-local `goto' (longjmp()) out of sleep().  Long-term sleepers can
and should sleep above PZERO, arranging to catch longjmp()s and clean
up after themselves as necessary.  (This is easier in newer Sun and
SysV kernels; it seems likely that 4.4BSD's synchronisation mechanisms
will have changed as well.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris