Date: Mon, 18 Apr 2005 10:28:07 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Archie Cobbs <archie@dellroad.org> Cc: freebsd-threads@freebsd.org Subject: Re: Bug with pthread_getspecific() and signals Message-ID: <Pine.GSO.4.43.0504181025080.28813-100000@sea.ntplx.net> In-Reply-To: <4263BC94.9040308@dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Apr 2005, Archie Cobbs wrote: > Daniel Eischen wrote: > >>Does POSIX say that pthread_getspecific can be used in signal handler ? > > > > I don't think using it in a signal handler should cause a problem > > for our implementation though. Probably the real problem is that > > the signal handler is not running in the expected thread. I'd > > double check the signal masks and make sure there is only one > > thread that could possibly handle the signal. > > This is a synchronous signal (SIGSEGV) and it's occurring in > application code. So it should be delivered to the thread that > caused it, right? That's what almost always happens. I don't think libc_r differentiates between synchronous and asynchronous signals. It'll look for threads in sigwait(), then sigsuspend(), then any thread with the signal unmasked. > Still working on a simple test case... if you want a large and complex > test case I have that already... :-) Try -stable or -current with libpthread and libthr. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0504181025080.28813-100000>