Date: Tue, 4 Dec 2001 11:42:36 -0600 From: Alfred Perlstein <bright@mu.org> To: Dan Eischen <eischen@vigrid.com> Cc: Louis-Philippe Gagnon <louisphilippe@macadamian.com>, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc_r pthread bug Message-ID: <20011204114236.H92148@elvis.mu.org> In-Reply-To: <3C0CC2FE.275F4C68@vigrid.com>; from eischen@vigrid.com on Tue, Dec 04, 2001 at 07:35:10AM -0500 References: <094601c179ea$7cca85c0$2964a8c0@MACADAMIAN.com> <Pine.SUN.3.91.1011130170847.14642A-100000@pcnet1.pcnet.com> <20011204021815.E92148@elvis.mu.org> <3C0CC2FE.275F4C68@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Dan Eischen <eischen@vigrid.com> [011204 06:26] wrote:
>
> There are already cancellation tests when resuming threads
> whose contexts are not saved as a result of a signal interrupt
> (ctxtype != CTX_UC). You shouldn't test for cancellation when
> ctxtype == CTX_UC because you are running on the scheduler
> stack, not the threads stack.
That makes sense, but why?
> You also have a bug in the
> way you changed the check for cancellation flags.
What?
> There only clean way to fix this is to add a return frame
> to the interrupted context so that it can check for cancellation
> (and other things) before returning to the threads interrupted
> context.
No way to work around this? Shouldn't the thread exit library
know which stack exactly to clean up even in the context of a
signal handler?
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
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?20011204114236.H92148>