Bug with pthread_getspecific() and signals

[Daniel Eischen]

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