Date: Mon, 18 Apr 2005 13:56:25 -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.0504181354560.58-100000@sea.ntplx.net> In-Reply-To: <4263C88F.4050007@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: > > 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? Yes, yes. > If it does, can you show me in which FreeBSD releases the bug is fixed? I don't know if it ever got fixed in libc_r. > 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. It should work correctly in both libpthread and libthr. libc_r is not being maintained. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0504181354560.58-100000>