Derrick Stolee <sto...@gmail.com> writes: >> close_commit_graph(); >> >> And after writing all data out (oh by the way, why aren't we passing >> commit_graph instance around and instead relying on a file-scope >> static global?)... > > Yeah, we should remove the global dependence. Is this a blocker for > the series?
I do not think it is such a big deal. It was just that I found it a bit curious while reading it through, knowing that you are already familiar with the work being done in that "the_repository" area. >> I _think_ the word "close" in the name hashclose() is about closing >> the (virtual) stream for the hashing that is overlayed on top of the >> underlying file descriptor, and being able to choose between closing >> and not closing the underlying file descriptor when "closing" the >> hashing layer sort of makes sense. So I won't complain too much >> about hashclose() that takes optional CSUM_CLOSE flag. > > I agree this "close" word is incorrect. We really want > "finalize_hashfile()" which may include closing the file. Yeah, that is much better. I do not think I'd mind seeing a prelim step at the very beginning of the series to just rename the function before the series starts to change anything else (there aren't that many callers and I do not think there is any topic in flight that changes these existing callsites). Or we can leave it for clean-up after the dust settles. Either is fine as long as we know that we eventually get there. > My new solution works this way. The only caveat is that existing > callers end up with this diff: > > - hashclose(f, _, CSUM_FSYNC); > + hashclose(f, _, CSUM_HASH_IN_STREAM | CSUM_FSYNC | CSUM_CLOSE); I think I am fine with that. It feels a bit nonsensical for a caller to ask fsync when it is not asking fd to be closed, as I'd imagine that the typical reason why the caller wants the fd left open is because the caller still wants to do something to it (e.g. write some more things into it) and a caller who would care about fsync would want to do so _after_ finishing its own writing, but that may be just me. >> And then we can keep the "FSYNC means fsync and then close" the >> current set of callers rely on. I dunno if that is a major issue, >> but I do think "close this, or no, keep it open" is far worse than >> "do we want the resulting hash in the stream?" > > I'm not happy with this solution of needing an extra call like this > in-between, especially since hashclose() knows how to FSYNC. I guess we are repeating the same as above ;-) As I said, I do not care too deeply either way. >> An alternative design of the above is without making >> CSUM_HASH_IN_STREAM a new flag bit. I highly suspect that the >> calling codepath _knows_ whether the resulting final hash will be >> written out at the end of the stream or not when it wraps an fd with >> a hashfile structure, so "struct hashfile" could gain a bit to tell >> hashclose() whether the resulting hash need to be written (or not). >> That would be a bit larger change than what I outlined above, and I >> do not know if it is worth doing, though. > > This certainly seems trickier to get right, but if we think it is the > right solution I'll spend the time pairing struct creations with > stream closings. I still do not think of a compelling reason why such an alternative approach would be worth taking, and do prefer the approach to let the caller choose when finalize function is called via a flag bit. Thanks.
