Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:03:13

Stefan Beller [off-list ref] writes:
quoted
quoted
After the series completes, this lock is only used in reflog_expire.
So I'd rather move it inside the function? Then we could run the reflog_expire
function in parallel for different locks in theory?
I am not sure about the "parallel" part, but I would imagine that it
is an essential prerequisite to move this outside the "client" code
if we want to later replace the backing storage of refs and reflogs
outside the filesystem, so from that point of view,  I think the
suggestion makes sense.

Thanks.
Sorry for the confusion. With parallel I mean,...
There is no confusion.  I understand exactly what you meant.

What I said was not sure was if "parallel" is a practical enough
possiblity to include into the set of value propositions the
suggested change to move the lock out of the "client" may give us.

In other words, "With this change, doing a parallel will become a
lot easier"---"Really?  It probably is not one of the harder part of
the problem if you really want to go parallel" was the discourse I
had in my mind.

;-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help