Francois Gouget [EMAIL PROTECTED] writes:
Yes, but it would also be the simplest implementation (overdesign can
be ugly too). And if it's the one off hack that it current looks like it
is, why not.
I propose to just let Alexandre decide which implementation, if any,
he thinks would be
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,
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
"Francois Gouget" [EMAIL PROTECTED] 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
On Tue, 10 Apr 2001, Dmitry Timoshkov wrote:
"Francois Gouget" [EMAIL PROTECTED] 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.
Francois Gouget [EMAIL PROTECTED] writes:
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
On 10 Apr 2001, Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
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
"Francois" == Francois Gouget [EMAIL PROTECTED] writes:
FrancoisWhich is why I suggested to specify +relay,+tid as the
Francois standard way to generate traces. But if you've already
Francois determined that the application you are debugging has only a
Francois single
Francois Gouget [EMAIL PROTECTED] writes:
Also, this is why I think it's nice to have the tid on each trace. If
not using +relay there is no indication of which thread is issuing the
trace.
I'm not opposed to a +tid option to switch on thread information on
all traces. But I think +relay
On 10 Apr 2001, Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
Also, this is why I think it's nice to have the tid on each trace. If
not using +relay there is no indication of which thread is issuing the
trace.
I'm not opposed to a +tid option to switch on
Another way to do this would be to hack the code decoding the
debugmsg settings to recognize +relay and set +tid at the same time, so
that '+relay'=='+relay,+tid'=='-tid,+relay' != '+relay,-tid'. But the
last two may be confusing.
what about a +notid channel ? I know it's against the
On Tue, 10 Apr 2001, Dimitrie O. Paun wrote:
On Tue, 10 Apr 2001, eric pouech wrote:
what about a +notid channel ? I know it's against the semantics of the
channel, but it's close to what you're looking for...
UGLY!
Yes, but it would also be the simplest implementation (overdesign
12 matches
Mail list logo
