Re: longjump && re-entrancy

From: William Pursell <bill.pursell@xxxxxxxxx>
Date: Thu, 31 Jan 2008 11:33:57 -0800 (PST)

On Jan 30, 4:04 pm, John Reiser <jrei...@xxxxxxxxxxxx> wrote:

William Pursell wrote:

setjumpbuf
fprintf() <-- interrupted
[in handler]:
longjump

Could hang if printf still has a lock on the FILE *.

Or does the stack unwinding from longjump magically
release the locks?

longjmp does no "unwinding" at all. It restores the
contents of CPU registers (and state of signal blockage,
if siglongjmp) but does *nothing* else.

So is it in fact unsafe to call longjmp() from a signal
handler if any signal-unsafe function may be
in the stack when the signal is received?
.

References:
- longjump && re-entrancy
  - From: William Pursell
- Re: longjump && re-entrancy
  - From: John Reiser

Prev by Date: Re: How to test packet loss rate ?
Next by Date: Re: How many App Types R there?
Previous by thread: Re: longjump && re-entrancy
Next by thread: getenv, putenv
Index(es):
- Date
- Thread

Relevant Pages

Re: longjump && re-entrancy
... handler if any signal-unsafe function may be ... That is one case in which it may be unsafe to use longjmp. ... the signal handler with no safety issue even though 'fprintf' would be ...
(comp.os.linux.development.apps)
Re: Signal-Unsafe Problem
... something to disable signal interrupt when I call the signal-unsafe ... which is used to disable signal interrupt. ... define the signals to block at the time of registering a handler. ... the default is to resume primitives. ...
(comp.os.linux.development.apps)
Re: longjump && re-entrancy
... handler if any signal-unsafe function may be ... in the stack when the signal is received? ... That is one case in which it may be unsafe to use longjmp. ... the signal handler with no safety issue even though 'fprintf' would be ...
(comp.os.linux.development.apps)