[RFA] More aggressive use of atexit locking

[Dave Korn]

On 02/02/2010 02:10, Christopher Faylor wrote:
> It seems like we should be locking both the feeder and the emptier for
> atexit operations shouldn't we?  Otherwise one can be deleting things
> while another is adding things.  This is especially important for the
> __cxa_* functions since the emptier can be called at any time, not just
> on process exit.

  Heh, there's always a catch.  Apparently it's legitimate for an atexit
callback function to register further atexit functions!  At the moment,
though, the initial atexit callback function is called with the atexit lock
held, so when it calls atexit, that attempts to take the lock again, resulting
in deadlock.

  The existing code in __call_exitprocs seems to be prepared for the
possibility of the atexit function list getting adjusted beneath its feet as a
result of actions taken by the function it's calling, so that should be OK.  I
considered unlocking the lock around the function callback, but that seemed a
bit risky, so this patch changes the lock to a recursive one, allowing the
nested acquire to succeed instead of deadlocking.

  Tested on i686-pc-cygwin, by running the g++ testsuite; the current state of
CVS HEAD trips this bug in two tests, leading to these failures:

> WARNING: program timed out.
> FAIL: g++.old-deja/g++.other/init18.C execution test
> WARNING: program timed out.
> FAIL: g++.old-deja/g++.other/init19.C execution test

  With this patch, those two tests pass.  Ok?

newlib/ChangeLog

	* libc/stdlib/__atexit.c (__atexit_lock): Initialise as recursive
	rather than non-recursive lock type.
	(__register_exitproc): Use recursive locking APIs on it.
	* libc/stdlib/__call_atexit.c (__call_exitprocs): Likewise.

    cheers,
      DaveK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atexit-recursive-locking.diff
Type: text/x-c
Size: 2051 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20100406/3bceb447/attachment.bin>