Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ncar!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: Kernel sleep priorities Message-ID: <11440@mimsy.UUCP> Date: 11 May 88 05:41:59 GMT References: <3950@killer.UUCP> <3951@killer.UUCP> <468@micropen> <625@vsi.UUCP> <9983@tekecs.TEK.COM> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 30 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