Traces: fs -> tid

[Francois Gouget]

On Tue, 10 Apr 2001, Dmitry Timoshkov wrote:

> "Francois Gouget" <fgouget at free.fr> wrote:
[...]
> >    So this patch adds a debug channel called 'tid' which activates
> > printing the tid as the first field of all traces. Actually, it might
> > make sense to merge 'tid' with the 'thread' debug channel.
> 
> The point was to be able to easy track down problems in multiprocess/multithreaded
> environment with just +relay trace. You never know, what surprise you will see
> analysing the traces from the news group.

   Yes, I agree with the switch to the tid instead of %fs. I can
understand too that it can be nice to have all the information we can
get from traces submitted on the newsgroup.


> Besides that, at least I always start
> searching for the problem with +relay trace: it would be too late to add +tid
> (or whatever) to notice, that the actual problem is related to process/thread
> interaction.

   But maybe we could ask for traces generated with +relay,+tid instead
of just +relay.
   Also when you're working on a specific application for which you have
determined that threads don't play a role, then you would have the
option of omitting the +tid to get simpler traces.


> Regarding too long lines: it is not the actual problem (doesn't it?). I would
> complain about too large files with the trace logs :-)

   Yes, large lines are annoying: they cause more wraps in emacs which
makes things less readable. Plus, I find it easier to scan for useful
information when there's not too much stuff at the end of the line.
   Plus when things seem thread related I find that it's nice to have
the thread id on each trace line. But I would not want it to be the
default.
   It's not a big deal anyway and I can quite easily patch things to be
better suited to any particular situation I'm working on.


--
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.