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

Carlos O'Donell wrote:
On Thu, Jun 5, 2008 at 5:40 AM, Mike Frysinger <> wrote:
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.

A very good suggestion. Anoop can you check with the official maintainers of the standard and get back to the list with your findings?


Please see for the discussions that happened on the opengroup list.

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

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.

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.

- Anoop

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