Re: [PATCH 1/2] Fix config lockfile handling.

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > AFAICT this cannot work.  At least not reliably.  An atexit() handler 
>> > will access all (even closed) lockfiles.
>> 
>> Correct.  It cannot be on the stack.
>
> Note that this behaviour will be another obstacle to libification.

By your definition of "obstacle", there is no work at all in
libification if the system is obstacle free.

Libification is all about removing run-once-and-exit and atexit() is
just a part of it.

I think we can do this step-by-step by first introducing a new function
"get_lockfile()" that takes a list of active lockfiles (perhaps that
would be a part of "client context" thing in the library) and gives back
a lockfile structure allocated on heap, registers it to the list of
lockfiles that need to be eventually cleaned up, and another function
"rollback_lockfiles()" that take the list of lockfiles in the "client
context" and rolls them all back.  Once there is such a "client contex",
in the current unlibified "main" routines can then declare a global
client context, obtain and use lockfiles for that context, and directly
call rollback_lockfiles() from the atexit() handler.

But that is all post 1.5.4.