Mark Brown wrote:
> All-
>
> Action Item 42 was:
> > The problem is the relationship between atexit() and dlopen() [and
> > dlclose()]. Should atexit registered funcs be called on dlclose.
> >
> > Should the behavior be run in dlcose,, or wait till exit? If wait till
> > exit, is undefined behavior allowed? Implementation defined either on
> > dlclose or on exit. Or make dlopen'ed modules forbidden to use atext.
>
> The recommendation (from Ulrich Drepper via Clive Feather) was a change in
> the atexit() text as shown below. Based on review I recommend that we
> accept this, with the further text changes I have added:
>
> > CX shading shown using {{shaded text}}
> >
> >
> > DESCRIPTION
> >
> > CX The functionality described on this reference page is aligned
>with
> > the ISO C standard. Any conflict between the requirements
> > described here and the ISO C standard is unintentional. This
> > volume of IEEE Std 1003.1-200x defers to the ISO C standard.
> >
> > The atexit() function registers the function pointed to by func,
> > {{CX}} to be called without arguments at normal program termination {{or
> > when the object defining the function is unloaded}}.
> > At normal program termination, all functions registered by the
> > atexit() function shall be called, in the reverse order of their
> > {{CX}} registration. {{On object unloading, any functions registered by
>the
> > object being unloaded are called in the reverse order of their
> > registration.}}
I think this should be "functions registered IN the object being unloaded".
First, the wording requires that the implementation of atexit() record not only
the
entry point (or procedure descriptor) of the exit handler, but also the PC of
the
code that called atexit() to register that handler. Furthermore, it means that
if I
dlopen libfoo.so and then (myself) call atexit() to register a routine exposed
by
libfoo.so as an exit handler, that exit handler should NOT be called when and if
libfoo.so is later unloaded (it was not registered BY the object being
unloaded).
> An exception is that a function is called after
> > any previously registered functions that had already been called
> > at the time it was registered.
I don't understand the intent of this. (Yes, I see that it is a minor
adjustment to
a previous addition to XSH6, which I apparently missed entirely.) Anyone know if
this is supposed to refer to the behavior of exit handlers declared within exit
handlers? Otherwise, how can exit handlers have already been called? And how
could
anyone expect it to be called before routines that were already called?
Regardless
of intent, this sentence (like the corresponding phrase in the current draft) is
awkward and unclear. The change history provides no explanation. (The only
justified changes are for alignment with C99, and this text does not come from
C99.)
This also brings up the minor issue that the description of exit handler calls
on
object unload doesn't state that such handlers be removed from the list of
handlers
to be called later... we wouldn't want them to be called again, particularly
after
the code has been removed from the address space. This seems "obvious", but
should
be explicit.
> > Normal termination occurs either by a call to
> > {{CX}} exit() or a return from main( ). {{Object unloading occurs by a
> > call to dlclose().}} At least 32 functions can be registered with
> > atexit().
> >
> > CX After a successful call to any of the exec functions, any
>functions
> > previously registered by atexit() shall no longer be registered.
>
> > After a successful call to any of the exec functions, any
> > functions previously registered by atexit() are no longer
> > registered.
/------------------[ yyyyyyyyyyyyyy@xxxxxxxxxx ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
|