Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-16 Thread Ronnie Sahlberg
On Tue, Apr 15, 2014 at 1:32 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 04/15/2014 06:33 PM, Ronnie Sahlberg wrote: On Mon, Apr 14, 2014 at 11:36 PM, Michael Haggerty mhag...@alum.mit.edu wrote: [...] I wonder, however, whether your approach of changing callers from lock =

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-16 Thread Junio C Hamano
Ronnie Sahlberg sahlb...@google.com writes: Currently any locking of refs in a transaction only happens during the commit phase. I think it would be useful to have a mechanism where you could optionally take out locks for the involved refs early during the transaction. So that simple callers

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-16 Thread Ronnie Sahlberg
On Wed, Apr 16, 2014 at 12:31 PM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com writes: Currently any locking of refs in a transaction only happens during the commit phase. I think it would be useful to have a mechanism where you could optionally take out locks

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-16 Thread Junio C Hamano
Ronnie Sahlberg sahlb...@google.com writes: I am not sure if that is the right way to go, or instead change all create/update/delete to take locks without adding a new primitive. ack. Hmph. When I say I am not sure, I dunno, etc., I do mean it. Did you mean by Ack I do not know, either, or

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-16 Thread Michael Haggerty
On 04/16/2014 09:31 PM, Junio C Hamano wrote: Ronnie Sahlberg sahlb...@google.com writes: Currently any locking of refs in a transaction only happens during the commit phase. I think it would be useful to have a mechanism where you could optionally take out locks for the involved refs early

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-15 Thread Michael Haggerty
On 04/14/2014 08:29 PM, Ronnie Sahlberg wrote: refs.c:ref_transaction_commit() intermingles doing updates and checks with actually applying changes to the refs in loops that abort on error. This is done one ref at a time and means that if an error is detected that will fail the operation

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-15 Thread Ronnie Sahlberg
On Mon, Apr 14, 2014 at 1:24 PM, Junio C Hamano gits...@pobox.com wrote: Thanks; will queue. Junio, Please defer queuing for now. I think we should convert more of the external callers to use transactions first. Once that is done and everything uses transactions I will re-send an updated

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-15 Thread Michael Haggerty
On 04/15/2014 06:33 PM, Ronnie Sahlberg wrote: On Mon, Apr 14, 2014 at 11:36 PM, Michael Haggerty mhag...@alum.mit.edu wrote: [...] I wonder, however, whether your approach of changing callers from lock = lock_ref_sha1_basic() (or varient of) write_ref_sha1(lock) to lock =

Re: [PATCH v4 0/3] Make update refs more atomic

2014-04-14 Thread Junio C Hamano
Thanks; will queue. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html