trace: add infrastructure to augment trace output with additional info
commitc69dfd24db21be54ec5a17bb3e07c81f4e96861a
authorKarsten Blees <karsten.blees@gmail.com>
Sat, 12 Jul 2014 00:02:18 +0000 (12 02:02 +0200)
committerJunio C Hamano <gitster@pobox.com>
Mon, 14 Jul 2014 04:25:18 +0000 (13 21:25 -0700)
treefc14e65849f5c67ccfb87c330c18307edcf16389
parent67dc598ec42ea25cda94ed8d283396c4ab385f50
trace: add infrastructure to augment trace output with additional info

To be able to add a common prefix or suffix to all trace output (e.g.
a timestamp or file:line of the caller), factor out common setup and
cleanup tasks of the trace* functions.

When adding a common prefix, it makes sense that the output of each trace
call starts on a new line. Add '\n' in case the caller forgot.

Note that this explicitly limits trace output to line-by-line, it is no
longer possible to trace-print just part of a line. Until now, this was
just an implicit assumption (trace-printing part of a line worked, but
messed up the trace file if multiple threads or processes were involved).

Thread-safety / inter-process-safety is also the reason why we need to do
the prefixing and suffixing in memory rather than issuing multiple write()
calls. Write_or_whine_pipe() / xwrite() is atomic unless the size exceeds
MAX_IO_SIZE (8MB, see wrapper.c). In case of trace_strbuf, this costs an
additional string copy (which should be irrelevant for performance in light
of actual file IO).

While we're at it, rename trace_strbuf's 'buf' argument, which suggests
that the function is modifying the buffer. Trace_strbuf() currently is the
only trace API that can print arbitrary binary data (without barfing on
'%' or stopping at '\0'), so 'data' seems more appropriate.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
trace.c
trace.h