Date: Mon, 18 Apr 2005 09:47:43 -0500 From: Archie Cobbs <archie@dellroad.org> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: Bug with pthread_getspecific() and signals Message-ID: <4263C88F.4050007@dellroad.org> In-Reply-To: <Pine.GSO.4.43.0504181025080.28813-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0504181025080.28813-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > 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. Well that would certainly explain my problem. By the way, this application is a Java virtual machine, trying to use signals to detect null pointer dereferences (and divide by zero). How is one supposed to do this if synchronous signals are not delivered to the thread that generated them? It then becomes impossible to detect in which thread the signal occurred. Is this a bug in libc_r? Does POSIX not specify this "same thread" behavior for synchronous signals? If it does, can you show me in which FreeBSD releases the bug is fixed? If not, how do other applications implement this?? > Try -stable or -current with libpthread and libthr. Unfortunately I don't have easy access to either such machine. I've been told that the same problem occurs with libthr though. In any case, if the thread library is not always sending synchronous signals to the generating thread then no further research is necessary. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4263C88F.4050007>