chris@mimsy.UUCP (Chris Torek) (04/30/88)
[I have redirected followups to comp.unix.wizards only.] In article <625@vsi.UUCP> friedl@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@mimsy.umd.edu Path: uunet!mimsy!chris