On Fri, Jan 23, 2015 at 4:14 PM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> writes: > >> By closing the file descriptors after creating the lock file we are not >> limiting the size of the transaction by the number of available file >> descriptors. >> >> When closing the file descriptors early, we also need to write the values >> in early, if we don't want to reopen the files. > > > I am not sure if an early return in write_ref_sha1() is entirely > correct. The unlock step was split out of write and commit > functions in the previous step because you eventually want to be > able to close the file descriptor that is open to $ref.lock early, > while still keeping the $ref.lock file around to avoid others > competing with you, so that you can limit the number of open file > descriptors, no?
yeah that's the goal. Though as we're in one transaction, as soon as we have an early exit, the transaction will abort. > > If so, shouldn't the write function at least close the file > descriptor even when it knows that the $ref.lock already has the > correct object name? The call to close_ref() is never made when the > early-return codepath is taken as far as I can see. > The goto cleanup; will take care of unlocking (and closing fds of) all refs -- 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
