SIGINFO and pthreads

[Daniel Eischen]

On Fri, 9 Jun 2006, Maxim Konovalov wrote:

> Daniel,
>
> On Thu, 8 Jun 2006, 18:52-0400, Daniel Eischen wrote:
>
>> On Thu, 8 Jun 2006, Maxim Konovalov wrote:
>>
>>> On Thu, 8 Jun 2006, 12:18-0400, Mikhail Teterin wrote:
>>>
>>>> четвер 08 червень 2006 00:17, Maxim Konovalov написав:
>>>>> Inline it if it's small.  Mailman strips most attachments.
>>>>
>>>> Damn... Yes, it is small -- this is just a demo program. Compile it first
>>>> as
>>>>
>>>>  cc -o t t.c
>>>>
>>>> Then -- run and try various keyboard signals like Ctrl-C, Ctrl-Z,
>>>> Ctrl-T (SIGINFO), or Ctrl-\. (It will not quit on its own, you'll
>>>> have to kill it from another prompt.)
>>>>
>>>> They will all work. Then -- recompile as
>>>>
>>>>  cc -o t -pthread t.c
>>>>
>>>> And run... This time around it will ignore the Ctrl-T, while
>>>> continuing to respond to others.
>>>>
>>>>> libpthread uses SIGINFO for dumping thread information to a file but
>>>>> looking over the code it seems it does allow to use SIGINFO to the
>>>>> app.
>>>>
>>>> I'd like to be able to disable the debugging feature or, at least,
>>>> force it to call my signal-handler AS EXPECTED AND DOCUMENTED, after
>>>> it is done with its own dumping.
>>>
>>> A funny thing your test program does work if you run it as
>>>
>>> LIBPTHREAD_DEBUG=yes ./t
>>>
>>> Try this patch:
>>
>> [ ... ]
>>
>>> For the first glance and quick test this check is not needed as we
>>> dump threads in already installed for SIGINFO _thr_sig_handler().  Of
>>> course we need our libpthreads experts review.
>>
>> Yes, that is a correct patch (remove the commented out section).
>> Please go ahead and commit!
>
> There is still a problem if user decided to SIG_IGN or SIG_DFL
> SIGINFO.  In this case threads dump stops working.  I don't know how
> important this fuctionality is so here is a more aggressive patch:

I could go either way on the issue.  This second patch looks
fine to me, so if you want to commit this one, that is fine
with me.

Thanks!

-- 
DE