[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: |
Mon, 21 Aug 2006 17:58:02 +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 Mon, 21 Aug 2006 10:46:36 +0200, Jan Djärv <address@hidden> said:
>>> Read the single exception: "when a signal interrupts an unsafe
>>> function and the signal-catching function calls an unsafe
>>> function, the behavior is undefined."
>>
>> So, you interpret that ``what are interrupted by a signal'' are all
>> the functions in execution on the whole threads in the process, not
>> just a single function in execution on the thread that the signal
>> is delivered to? I don't think that is a natural interpretation.
> I don't see the line "what are interrupted by a signal" in the
> quote, so I'm not sure what you mean.
> My interpretation is that it is unsafe to call lock/unlock from a
> thread and from a signal handler at the same time, if they operate
> on the same mutex. That is what the original hang was all about.
The standard says "when a signal interrupts an unsafe function ...".
My interpretation is that a signal interrupts *only* the function in
execution on the thread that the signal is delivered to, but the
signal does not interrupt the functions in execution on the other
threads.
>> As I said earlier, the current Emacs implementation calls malloc
>> within a signal handler with the help of BLOCK_INPUT relying on the
>> assumption that it is safe unless the signal interrupted
>> malloc-related functions.
> But this only works for the Emacs main thread, not the Gnome
> threads.
And according to the above interpretation, functions that are executed
on non-main threads are irrelevant.
YAMAMOTO Mitsuharu
address@hidden
- why "in_sighandler"?, Stefan Monnier, 2006/08/20
- Re: why "in_sighandler"?, Jan D., 2006/08/20
- Re: why "in_sighandler"?, Stefan Monnier, 2006/08/20
- Re: why "in_sighandler"?, YAMAMOTO Mitsuharu, 2006/08/20
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/21
- Re: why "in_sighandler"?, YAMAMOTO Mitsuharu, 2006/08/21
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/21
- Re: why "in_sighandler"?, YAMAMOTO Mitsuharu, 2006/08/21
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/21
- Re: why "in_sighandler"?,
YAMAMOTO Mitsuharu <=
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/21
- Re: why "in_sighandler"?, YAMAMOTO Mitsuharu, 2006/08/21
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/22
- Re: why "in_sighandler"?, YAMAMOTO Mitsuharu, 2006/08/22
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/22
- Re: why "in_sighandler"?, YAMAMOTO Mitsuharu, 2006/08/22
- Re: why "in_sighandler"?, Jan Djärv, 2006/08/22
- Re: why "in_sighandler"?, Andreas Schwab, 2006/08/22
Re: why "in_sighandler"?, Richard Stallman, 2006/08/21