Re: [PATCH v2 20/27] update-ref --stdin: Reimplement using reference transactions

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 4, 2014, 05:02 UTC
Message-ID: <533E3CF8.5080506@alum.mit.edu>
In-Reply-To: <xmqq61mqs8wl.fsf@gitster.dls.corp.google.com>

On 04/03/2014 05:57 PM, Junio C Hamano wrote:

Show 15 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> I assumed that rolling back a non-consummated transaction in the case of
>> early program death should be the responsibility of the library, not of
>> the caller.  If I'm correct, the caller(s) won't have to be modified
>> when the atexit facility is added, so I don't see a reason to add it
>> before it is needed by a concrete backend.
>>
>> But you suggest that the caller should be involved.
> 
> I didn't say "should".  If the library can automatically rollback
> without being called upon die() anywhere in the system, that is
> better.  The suggestion was because I didn't think you were shooting
> for such a completeness in the library part, and a possible way out
> is for the caller to help.

I was assuming that any ref backends that required rollback-on-fail would register an atexit handler and a signal handler, similar to how lock_file rollbacks are done.

I admit that I haven't thought through all the details; for example, are there restrictions on the things that a signal handler is allowed to do that would preclude its being able to rollback the types of transactions that back ends might want to implement? (Though if so, what hope do we have that the caller can do better?)

So, if somebody can think of a reason that we would need to involve the
caller in cleanup, please speak up.  Otherwise I think it would be less
error-prone to leave this responsibility with the individual back ends.
 (And if something unexpected comes up, we can make this change later.)

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/