Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
