This is the mail archive of the 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()

On Thursday 05 June 2008, Anoop wrote:
> Carlos O'Donell wrote:
> > On Wed, Jun 4, 2008 at 9:13 AM, Anoop <> wrote:
> >> Though it doesnt say it is thread safe, atexit() is not listed in the
> >> thread-unsafe functions listed in sextion 2.9.1 -
> >>
> >>ml#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?

honestly, i dont think this discussion is going to go anywhere.  you should 
post your query to the austin group mailing list and ask straight out: does 
atexit() and exit() need to be safe wrt each other.

Attachment: signature.asc
Description: This is a digitally signed message part.

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