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