On Wed, Nov 30, 2005 at 09:13:55PM +0000, Christos Zoulas wrote:
> Pavel Cahyna  <pcah8322@artax.karlin.mff.cuni.cz> wrote:
> >On Wed, Nov 30, 2005 at 08:54:55PM +0000, Rui Paulo wrote:
> >> signal(7):
> >> 
> >>      A function that is async-signal-safe is either reentrant or non-inter-
> >>      ruptible by signals.  This means that they can be used in signal handlers
> >>      and in the child of threaded programs after doing fork(2).
> >> 
> >>      The following functions are async-signal-safe.  Any function not listed
> >>      below is unsafe to use in signal handlers.
> >
> >Thanks for the reference. That is IMHO a bug, because POSIX says :
> >
> >"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."
> >
> >So it should be perfectly legal to call printf() from a signal handler
> >which is carefully blocked around calls to unsafe functions, because this
> >does not fall in the exception above, no?
> 
> It is not legal. Each invocation of the "unsafe" function needs to
> be protected from being interrupted by a signal for this to work.
> I.e.  you are in the middle of a printf, you get a signal, you end
> up in the signal handler, you call your protected printf that
> trashes the internal stdio state. Unfortunately you cannot predict
> which "unsafe" function might call another "unsafe" function, so
> you'll have to protect all of them.

Thats what I have said, no? But that's not what the manual page imply.

Pavel