On Tue, 10 Apr 2001, Dmitry Timoshkov wrote:
"Francois Gouget" fgouget@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@free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.