SIGINFO interrupts connect() with libpthread

[Daniel Eischen]

On Sat, 8 Oct 2005, Robert Watson wrote:

>
> On Sat, 8 Oct 2005, Daniel Eischen wrote:
>
> > It only works with libc_r because libc_r wraps all these calls
> > (including connect()) with poll().  Obviously we're not going to do that
> > with libpthread.  You're only seeing it with SIGINFO because we use
> > SIGINFO as a debugging signal for libpthread (to dump thread state).
> > libpthread doesn't install any other signal handlers unless the
> > application does.  We could use a different signal or not use SIGINFO at
> > all.
>
> Ah, so this is why my /tmp is full of garbage :-):
>
> As you might guess, I like to hit ^T to find out what an application is
> doing.  Regardless of whether the application has its own SIGINFO handler
> or not.  libpthread should not implement SIGINFO unless some or another
> special circumstances apply -- environmental variable, or compile option,
> or such.

Well, libc_r has been that way for years and it just carried over into
libpthread.  We could add another signal, but I'm confused on how signals
should be added.  We allow up to 128 signals, but only have 31 (up to
SIGUSR2) defined and usable.  When SIGTHR was added, NSIG wasn't bumped
so it isn't found in valid signals by kill(1), and anything added after
it would not be either without bumping NSIG.  The comments for NSIG
also say "number of old signals" and implies that new signals can be
added without bumping NSIG.  So either the comment is wrong, or kill(1)
is wrong.  And lib/libc/gen/siglist.c also bases everything on NSIG.

-- 
DE