Re: why "in_sighandler"?

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 22 Aug 2006 10:23:40 +0200, Jan Djärv <address@hidden> said:

>>> How can it be otherwise?  If you only have one program counter,
>>> that program counter must be changed to the signal handler no
>>> matter how many threads you have, i.e. any previous execution
>>> (regardless of thread) is interrupted.
>> 
>> Not-running threads have already been *interrupted* by context
>> switching.  Are they interrupted by a signal again?

> What exactly do you mean by interrupted?  In the sense that they
> don't get to execute, yes they are interrupted.

I should have used "..." instead of *...*.  I tried to follow your
definition of "interrupt".

> When a signal handler is running, no threads can run (on a single
> CPU machine), hence they are all interrupted.

The signalled-thread is/becomes running just before the signal handler
is executed.  The thread is not "interrupt"ed by context switching,
but by a signal.

>> I don't understand why non-signalled threads are relevant as long
>> as a signal handler only executes thread-safe functions.  The
>> problem of async-signal-unsafe function is that a thread that took
>> a lock in the normal context may try to take the same lock in a
>> signal handler context.  The thread cannot go back to the normal
>> context where the lock will be released afterwards, but just waits
>> for the lock in the signal handler.  As a result, the thread gets
>> stuck.  That's irrelevant to the other threads.

> That can't be it.  The mutex is recursive, so a thread is able to
> take it multiple times.

Recursive mutex is implemented using a simpler lock mechanism.  That's
why I used the term "lock" instead of "mutex".

                                     YAMAMOTO Mitsuharu
                                address@hidden