Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> Are you sure that it's not well-defined? We open the path with O_APPEND, >> which means every write() will be atomically positioned at the end of >> file. So we would never lose or overwrite data. >> >> We do our own buffering in a strbuf, writing the result out in a single >> write() call (modulo the OS returning a short write, but that should not >> generally happen when writing short strings to a file). So we should get >> individual trace lines as atomic units. >> >> The order of lines from the two processes is undefined, of course. > > Correct. But I am more worried about the "mixed/overwriting" > breakage, if there is one; it means we may need to be prepared for > systems that lack O_APPEND that works correctly. I initially just > assumed that it was what Dscho was seeing, but after re-reading his > message, I am not sure anymore. > > I think the "do not trace the other side" approach you suggest for > these tests that only care about one side is more appropriate > solution for this particular case. We then do not have to worry > about overwriting or output from both sides mixed randomly. A concluding sentence I forgot to add, after saying "this is simpler and better to fix test breakage", was But if we really are seeing O_APPEND breakage, a mandatory locking mechanism like this one might be necessary to work around it (I seriously hope we do not have to, though). Sorry for an additional noise.
