Kernel sleep priorities

[Chris Torek]

[I have redirected followups to comp.unix.wizards only.]

In article <625 at vsi.UUCP> friedl at vsi.UUCP (Stephen J. Friedl) writes:
>     I would be interested to hear from driver writers who are
>more familiar with this: how does one determine whether a sleep
>should be interruptible or not?  Why aren't they all this way
>(not a plea, just a question)?

Simple: sleeps should be interruptable if and only if there is no
state left to clean up after such an interrupt.

It is possible to sleep interruptably, yet keep state, if you are
willing either to notice stale states and clean up later, or to use
`setjmp' to catch signals through kernel sleeps.  Alas, there is
only a single place in which the setjmp data is (are?) stored,
`u.u_qsave' in 4.3BSD, and it is usually in use by the time you
reach a driver.

Since they are really used as an unwind-protect, kernel `setjmp's
ought to be stackable: something like

	label_t prev;
	if (catch(&prev, &u.u_qsave)) {
		/* clean up state */
		throw(&prev);
		/* NOTREACHED */
	}

Since the second argument to this `catch' routine, or the first
argument to the kernel setjmp, is always[*] `&u.u_qsave', it should
probably be eliminated entirely.  ([*]In 4.3BSD, at least, where
fork context is saved with `savectx'.)
-- 
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