This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix the race between atexit() and exit()


Carlos O'Donell wrote:
On Wed, Jun 4, 2008 at 9:13 AM, Anoop <acv@linux.vnet.ibm.com> wrote:
Though it doesnt say it is thread safe, atexit() is not listed in the
thread-unsafe functions listed in sextion 2.9.1 -
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_01
where it says - All functions defined by this volume of IEEE Std 1003.1-2001
shall be thread-safe, except that the following functions need not be
thread-safe.

Once you call exit(), don't all the consequence apply e.g. the parent process is destroyed, and all children are zombies. This implies that any additional atexit() registered handlers do *not* have to be run since the parent has already exited, and will never do so again?

Lets take a simple case, where a thread calls atexit(), while exit() is
traversing the __exit_funcs list in the main thread. Further assume that
atexit() incremented __exit_funcs->idx and changed the flavor of the handler to
ef_us, when exit reached this index (handler) traversing the list. Since the
flavor is ef_us, it will ignore this handler. (of course there is no handler to
call now). But atexit() later adds the function pointer, changes the flavor
and comes out registering the handler successfully. Isn't this a violation of
the POSIX standard in that it failed to invoke a successfully registered atexit
handler?

-Anoop







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]