Re: Proposal for 2.8: Glog

[Tor Lillqvist <tml iki fi>]

Tim Müller writes:
 > I'd be happy to whip up a preliminary patch against GLib if this is
 > something people feel might be worth having in GLib. 

Yes!

A tracing facility would be nice. I have suggested such earlier. Do
you have a pointer to some on-line documentation on Glog's features?
(Is that its current name, or a proposed new name?)

At least for my needs, the following features would be essential
(i.e., I have at times hacked together stuff like this manually by
adding code temporarily to sources I've been debugging):

- It should be possible to redirect the output of each process, or
each thread even, to a separate file. The trace file names could be
configurable. For instance so that a %p would expand to the pid, %t
thread id, %n to the process name. Etc.

- The format of each line could have optional parts: at least source
file name, line number, process id, thread id, timestamp (with
settable precision). Possibly things like cpu usage, system call
count, etc. (Maybe that is overdoing it.)

- In case several threads output traces to the same file, it would be
essential that each line is written atomically. Is it enough that each
line is written using one write() system call (on Unix) to achieve
this? Presumably not, so some locking must be used.

- On Win32, maybe it should be selectable to direct the output to
OutputDebugString(). On Unix, to syslog().

- Trace invokations in the source code should be very
non-intrusive. Some very short macro call with no parameters if you
just want a basic line with no specific information, just a basic
where and when.

--tml