Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Oct 2001 16:04:14 +0300
From:      Peter Pentchev <roam@ringlet.net>
To:        Greg Lehey <grog@FreeBSD.org>
Cc:        Julian Elischer <julian@elischer.org>, Gersh <gersh@sonn.com>, Bernd Walter <ticso@mail.cicely.de>, Anjali Kulkarni <anjali@indranetworks.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: setjmp/longjmp
Message-ID:  <20011002160414.B10919@ringworld.oblivion.bg>
In-Reply-To: <20011001105624.C31215@wantadilla.lemis.com>; from grog@FreeBSD.org on Mon, Oct 01, 2001 at 10:56:24AM %2B0930
References:  <Pine.BSF.4.21.0109280834410.57111-100000@tabby.sonn.com> <Pine.BSF.4.21.0109281010570.71138-100000@InterJet.elischer.org> <20011001105624.C31215@wantadilla.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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'.

G'luck,
Peter

-- 
Do you think anybody has ever had *precisely this thought* before?

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011002160414.B10919>