On Wed, Jun 08, 2016 at 12:48:36PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > That made me wonder if we could repeatedly reuse a buffer attached to > > the file descriptor. And indeed, isn't that what stdio is? The whole > > reason this buffer exists is because we are using a direct descriptor > > write. If we switched this function to use fprintf(), we'd avoid the > > whole buffer question, have a fixed cap on our memory use (since we just > > flush anytime the buffer is full) _and_ we'd reduce the number of > > write syscalls we're making by almost a factor of 100. > > The primary reason why we avoid stdio in the lower level part of I/O > is that the error reporting and handling is horrible. > > e.g. c.f. http://article.gmane.org/gmane.comp.version-control.git/27019 > > Otherwise, I'd agree with your "Why aren't we using stdio if > counting and avoiding overflow is so hard?". I agree it can be confusing (especially on the output side your errors are likely deferred until the next flush). But in this particular case, I think it's an improvement (see the patch I just sent and its discussion of error handling). I also think we could smooth over the rough edges by wrapping the complexity (we already have fprintf_or_die, which arguably could be used in this case, but I went with the solution that stayed closer to what the original code was doing). And if stdio is truly too horrible, I'd suggest we implement our own buffered I/O. Because that's effectively what such call-sites are doing, but in a really ad-hoc and non-performant way. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html