[MERGE/RFC] Flush .bzr.log periodically

[Martin Pool]

On  7 Jan 2009, John Arbash Meinel <john at arbash-meinel.com> wrote:
> I wrote this a while back when running long conversions on windows.
> 
> It seems that when writing to a buffered file, the buffer is in user
> space, and if you kill the process early, it never gets written.
> 
> Further, it only flushes after a number of bytes are written, and not
> even line-based.
> 
> I believe I remembered us not wanting to call .flush() all the time,
> because of its performance overhead, so this call only flushes if it
> hasn't written anything for 2s.
> 
> I'm not settled that we need it, but it did make following the log file
> on windows during a long running process nicer.
> 
> (I haven't broken it out into a mergable patch yet, but the change is
> pretty small).
> 
> I know there is a comment that the tracefile is line buffered, but I can
> guarantee that isn't the case on Windows.

I don't think it's the case anywhere.

We used to have the approach in some places of writing a lot of data to
the file unconditionally, in the hope that if someone hit a one-off
failure we'd have a record of what happened leading up to that point.
That works well in some programs, but not in Bazaar because logging
enough data to be useful too expensive, and it generally turns out not
to help that much compared to getting a copy of the traceback and maybe
the dirstate or repository.  So now we don't generally write much unless
you give a -D option.  (There are some odd exceptions.)

Given that, we can bear to do a bit more work in the mutter function,
like checking the time.  In fact you could even change it back to using
line buffering, if that's more useful, and if it turns out not to have a
noticeable cost.

But I was pretty sure from looking at -Dhpss output on Linux that in
fact it was line buffered, or not too far from it.  You can see them
in nearly real time.

-- 
Martin      <http://launchpad.net/~mbp>