Geoff Clare wrote:
Clive D.W. Feather <clive@demon.net> wrote, on 09 Jun 2008:
Dave Butenhof said:
Except that here we're talking about synchronization between two
concurrently executing threads. It IS possible for atexit() to be
invoked after exit() starts, but not from another atexit handler -- it's
called from another thread.
Ah. Threads.
Okay, just ignore me.
Actually, I thought you had a valid point, which Dave doesn't
seem to have taken into account.
What?
I was NOT trying to re-state the issue from scratch. I was merely
explaining the hole in his logic.
Dave said:
| Except that here we're talking about synchronization between two
| concurrently executing threads. It IS possible for atexit() to be
| invoked after exit() starts, but not from another atexit handler -- it's
| called from another thread.
Perhaps he meant to say "but not only from another atexit handler", but
without the "only" this suggests that he thinks atexit handlers are not
allowed to call atexit(), when in fact they are.
You're over-analyzing a simple statement and ignoring the context. I was
never claiming to re-state the general POSIX rule from scratch. In
response to a specific statement that atexit() can be called after
exit() only from an atexit() handler, I pointed out that it can in fact
be called after exit() but not from an atexit() handler. This is a
simple, direct, and correct statement. I was never attempting or
claiming to be proposing new all-encompassing language for the standard.
So exit() cannot lock the handler list and keep it locked until it calls
_exit(); it must unlock the list during the call to each handler[*].
Consequently it is possible for other threads to register new handlers
while exit() is processing the handler list (as long as the list is not
empty). The rule from the C Standard about handler ordering applies to
new handlers regardless of whether they are added by one of the handlers
or by another thread.
* Actually, I suppose it could use a recursive mutex, which would allow
atexit() to lock it again if called from the same thread that called
exit() (i.e. from a handler), but not if called from a different thread.
It shouldn't matter to applications either way, since the process is
about to exit anyway.
Yes, that might be one possibility. It would be a mistake, however, to
require a recursive mutex, or that another thread trying to register an
atexit handler will block until the process terminates. The list could
be managed, for example, as a simple lock-free list. An atexit handler
registered asynchronously from another thread during exit() processing
MAY or MAY NOT be called by the thread executing exit() depending on the
implementation strategies.
|