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
andrew@frip.gwd.tek.com (Andrew Klossner) (05/10/88)
"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."
That's not a problem: save u.u_qsave in an "auto" structure, use it for
"setjmp", then restore it.
(BTW, under system V release 3, you can tell sleep to return to you on
interrupt rather than to the outstanding setjmp, bypassing the need to
save/restore u.u_qsave. OR PCATCH into the second parameter and sleep
will return 1 if the sleep was interrupted, 0 if it wasn't.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]chris@mimsy.UUCP (Chris Torek) (05/11/88)
Me: >>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. In article <9983@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) answers: >That's not a problem: save u.u_qsave in an "auto" structure, use it for >"setjmp", then restore it. Oops. For some reason, when I wrote the >> text above, I thought that label_t was an array type. It is not, so one can simply write label_t prev; prev = u.u_qsave; if (setjmp(&u.u_qsave)) { ... clean up longjmp(&prev); } ... make a mess, and call sleep u.u_qsave = prev; return; Of course, even if label_t were an array type, you could still do this, using bcopy instead of assignment. (Not that the resulting code is any different!---though it should be: label_t could be 2 longs in 4.3BSD, rather than 14. Then the compiler would use movq.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
vandys@hpindda.HP.COM (Andy Valencia) (05/11/88)
/ hpindda:comp.unix.wizards / andrew@frip.gwd.tek.com (Andrew Klossner) / 10:41 pm May 9, 1988 / >(BTW, under system V release 3, you can tell sleep to return to you on >interrupt rather than to the outstanding setjmp... I'm doing drivers for Microport UNIX (yeh, yeh, gimme a break). It also has this feature. Are you sure it isn't just release 2 that provided this function? Andy Valencia vandys%hpindda.UUCP@hplabs.hp.com