On Tue, 2 Oct 2001, Peter Pentchev wrote:
> On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote:
> > [Format recovered--see http://www.lemis.com/email/email-format.html]
> >
> > On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote:
> > > On Fri, 28 Sep 2001, Gersh wrote:
> > >> On Fri, 28 Sep 2001, Bernd Walter wrote:
> > >>> On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote:
> > >>>> Does anyone know whether it is advisable or not to use
> > >>>> setjmp/longjmp within kernel code? I could not see any
> > >>>> setjmp/longjmp in kernel source code. Is there a good reason for
> > >>>> this or can it be used?
> > >>>
> > >>> You need to look again, it's used in several places in the kernel.
> > >>
> > >> Look at sys/i386/i386/db_interface.c
> > >
> > > Yeah but it would probably be a pretty bad idea to use it without
> > > very careful thought. Especialy with the kernel becoming
> > > pre-emptable in the future..
> >
> > Can you think of a scenario where it wouldn't work? Preemption
> > doesn't tear stacks apart, right?
>
> How about a case of a longjmp() back from under an acquired lock/mutex?
> Like function A sets up a jump buffer, calls function B, B acquires
> a lock, B calls C, C longjmp()'s back to A; what happens to the lock?
>
> It would work if A were aware of B's lock and the possibility of a code
> path that would end up with it still being held; I presume that this is
> what Julian meant by 'very careful thought'.
pretty much...
>
> G'luck,
> Peter
>
> --
> Do you think anybody has ever had *precisely this thought* before?
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
