Co-opting signals

[Girish Hilage]

Thanks Kip.
My application is using pthread_kill() to send SIGUSR1 to child threads.
I am using 4.x and I want to make sure if SIGUSR1 is not being co-opted.
Or for a complete information what all signals are being co-opted and
how should I find out from libc_r source that it's not being co-opted? I
grep'ed for SIGUSR1 in libc_r source code and did not find it being used
anywhere so I came to the conclusion that it's not being co-opted. Is
greping through the source code enough to determine that the signal is
not being used?

On Mon, 2007-10-08 at 23:36 -0700, Kip Macy wrote:

> libc_r has been disconnected from the build for some time.
> 
> On 10/8/07, Girish Hilage <girish_hilage at persistent.co.in> wrote:
> > Thanks Daniel for your response.
> > But I want to know if libc_r is still(in it's latest version) co-opting
> > signals internally?
> >
> > Regards,
> > Girish
> >
> > On Mon, 2007-10-08 at 15:01 -0400, Daniel Eischen wrote:
> >
> > > On Mon, 8 Oct 2007, Girish Hilage wrote:
> > >
> > > > Hi,
> > > >
> > > >    I heard that, user level pthreads co-opt some signals to get their
> > > > job done.
> > > >    Can anybody please let me know which are these signals?
> > >
> > > Not true since 4.x since only libc_r did this.  Since FreeBSD 5.x,
> > > the default thread libraries (libpthread/libkse, and libthr) do
> > > not use signals for their implementation.  Under 5.x and subsequent,
> > > just compile and link your program normally (use -pthread or
> > > -lpthread when linking) and you will get the default thread
> > > library (not libc_r, which has been deprecated in 7.x/current).
> > >
> > _______________________________________________
> > freebsd-threads at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> > To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
> >