Re: Reentrancy
"K?r?at" <kursattheking@gmail.com> wrote in message
news:uYkHz8auJHA.2596@TK2MSFTNGP02.phx.gbl...
"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:OP9ogGWuJHA.3988@TK2MSFTNGP05.phx.gbl...
Also, different environments may have synchronous or asynchronous signal
handling. With synchronous signal handling, like on Windows, only
functions that call user-defined callbacks have to be designed for
re-entrancy. With asynchronous signal handling, like Unix, a signal can
arrive at anytime and a signal handler can start executing almost
anywhere, so even if your function does not call any callbacks, it still
needs to be concerned with re-entrancy. asctime is a classic example --
it is not re-entrant, but on Windows this is never a problem, because
there's no way to re-enter it. On Unix, you'd better avoid calling
asctime from inside a signal handler because it might have been running
when the signal arrived.
What do you mean by saying "signal handling" ? Handling interrupts ?
Windows Messages? or What ?
Signal handling is a concept borrowed from Unix but it is included in the C
standard library. You can set up signal handlers and raise signals on
Windows, although the behavior is somewhat different from the usual Unix
semantics.
http://msdn.microsoft.com/en-us/library/xdkz3x12.aspx
Of these, on Windows it looks like SIGFPE could be considered asynchronous,
as although entry points are predictable (floating point instructions only),
there's no explicit request to dispatch callbacks. The other signals are
only dispatched by a call to raise.
Window messages and APCs all fall into the category of callbacks (APCs are
misnamed, they are synchronized to the program voluntarily and explicitly
entering alertable waits).