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()


On Tue, Jun 10, 2008 at 8:25 AM, Anoop <acv@linux.vnet.ibm.com> wrote:
> Please see https://www.opengroup.org/austin/mailarchives/ag/ for the
> discussions that happened
> on the opengroup list.

Interesting discussion.

> The result of this discussion as I would infer is that exit() and atexit()
> need to be safe with each other in the matter of keeping the list
> consistent.
> But it CAN'T be guaranteed that, if atexit() is called, 'during or after'
> exit() is called,
> from a different thread, the handler that atexit() tries to register will be
> invoked by exit().

I agree.

> The proposed patch does 2 things -
> 1. Keeps the list in a consistent state by protecting it with lock
> 2. Fails the atexit() registrations after exit() finishes processing the
> list.

That sounds reasonable.

> Accommodating as many handlers as possible is the important and right thing
> to do. But you cant
> avoid the "visibility problem" where a new list head appears only after
> exit() processing is over.
> This problem should be taken care of, more by an application programmer than
> by glibc.
> Making the registration fail may not be of any worth as the thread might not
> get a chance to take
> any action afterwards, but from glibc perspective this is just for the sake
> of keeping with the standard.

Where's the patch?

Cheers,
Carlos.


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