Traces: fs -> tid

[Francois Gouget]

I noticed that fs was replaced by tid in relay (and snoop & co too
now). I propose a slightly different version based on the following
premises:

* when suspecting a threading problem it could be nice to tag each
trace with the id of the thread that emits it

* when there's no thread issue, then fs and tid are unnecessary and
only clutter the traces by making lines longer and harder to read

* I find that lines are more readable if the thread id comes first as
it's always the same length and doesn't mess up the alignment of the
other fields

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.

'Screenshot':

08063178:Call user32.DispatchMessageA(405b6e50) ret=00402135
08063178:trace:relay:WINPROC_CallWndProc (wndproc=0x401c74,hwnd=00000138,msg=WM_SYSCOMMAND,wp=0000f060,lp=00000000)
08063178:Call user32.DefWindowProcA(00000138,00000112,0000f060,00000000) ret=0040206c

Comments?

Changelog:

* dlls/ntdll/ntdll.spec
   Declare the tid debug channel

* dlls/ntdll/debugtools.c,
   relay32/relay386.c,
   relay32/snoop.c
   Output the current thread id as the first field if tid is turned on

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
                           La terre est une bêta...

[Francois Gouget]

I forgot: if not applying the previous patch then it would probably
be a good idea to apply the attached patch to dlls/ntdll/critsection.c
to output the tid instead of fs so that one can relate it to the other
tids.

(if the previous patch is applied then this one is unnecessary since
ERR will output the tid for us if +tid is set)

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
                      Computers are like airconditioners
                They stop working properly if you open WINDOWS

[Dmitry Timoshkov]

"Francois Gouget"  wrote:
> I noticed that fs was replaced by tid in relay (and snoop & co too
> now). I propose a slightly different version based on the following
> premises:
> - when suspecting a threading problem it could be nice to tag each
>
> trace with the id of the thread that emits it
> - when there's no thread issue, then fs and tid are unnecessary and
>
> only clutter the traces by making lines longer and harder to read
> - I find that lines are more readable if the thread id comes first as
>
> it's always the same length and doesn't mess up the alignment of the
> other fields
>
> 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. 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.

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

[Francois Gouget]

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