[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why "in_sighandler"?

From: YAMAMOTO Mitsuharu
Subject: Re: why "in_sighandler"?
Date: Tue, 22 Aug 2006 17:34:51 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]