> In any case, it clearly would not be acceptable for the application to
> crash because exit() found the list of atexit() handlers in an
> inconsistent state, for example. Nor for atexit() to crash because
> exit() might modify the list.
Agreed.
> There is, however, always a "race" between callers of dependent
> functions. That is, it's not possible to define exit() so that it's
> guaranteed to see all atexit() handlers that the application might ever
> register (concurrently or in the future). But either exit() shall see
> the new atexit handler and invoke it properly OR exit() shall not see
> the new atexit handler and will proceed as if this call to atexit() had
> not happened. Logically, exit() occurs either before or after atexit()
> insertion; never "during".
I disagree here.
An atexit() handler is either installed before the call to exit(), or while
exit() is processing. In the former case, the handler must be called for
obvious reasons. In the latter case it is installed by another atexit()
handler. The C Standard is clear that an atexit() handler installed by
another atexit() handler is called after that one returns and before what
would have been the next one is called. In other words, it has a stack
model:
* atexit() pushes the handler on to the stack.
* exit() effectively goes:
while stack is not empty
{
pop handler from stack
call handler
}
--
Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc | |
|