Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: xon/xoff, signals, hangup
Message-ID: <14646@mimsy.UUCP>
Date: 20 Nov 88 05:50:50 GMT
References: <260@eda.com> <773@wsccs.UUCP> <14526@mimsy.UUCP> <460@auspex.UUCP> <2269@ficc.uu.net>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 40

In article <2269@ficc.uu.net> peter@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@mimsy.umd.edu	Path:	uunet!mimsy!chris