[Top][All Lists]

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

Re: why "in_sighandler"?

From: Jan Djärv
Subject: Re: why "in_sighandler"?
Date: Tue, 22 Aug 2006 08:38:54 +0200
User-agent: Thunderbird (X11/20060808)

YAMAMOTO Mitsuharu skrev:
On Mon, 21 Aug 2006 13:32:30 +0200, Jan Djärv <address@hidden> said:

A signal interrupts all threads on a uni-processor machine.

I can hardly believe that.  Can you give some references saying so?

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.

The same quote from IEEE Std 1003.1 again:

  All functions not in the above table are considered to be unsafe
  with respect to signals. In the presence of signals, all functions
  defined by this volume of IEEE Std 1003.1-2001 shall behave as
  defined when called from or interrupted by a signal-catching
  function, with a single exception: when a signal interrupts an
  unsafe function and the signal-catching function calls an unsafe
  function, the behavior is undefined.


It says "interrupted by a signal-catching function".  And the
signal-catching function is executed on the thread that the signal is
delivered to.  Given no other notes, it is natural to interpret that a
signal only interrupts the function in the thread that the
signal-catching function is executed.

"Multithreading in the Solaris Environment" says:

  An asynchronous signal interrupts the signalled thread at some
  arbitrary point in its execution

It is semantics. When I say interrupted I mean that the signal handling function starts to run. You obviously mean something else. But this is a side issue, it has more to do with reentrance of the function interrupted rather than which thread is currently running.

        Jan D.

reply via email to

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