thread-specific use of Debug object

[Dave]

Nope. Here's the situation:

o You create a thread, and set it for debug
o The thread dies naturally
o A third party library creates a new thread, and it gets the same
hashcode as the first thread
o The third party library writes some debug output
o Oops - you incorrectly include it with your own output

Nope. Since I've already stipulated that I control the thread that registers
itself, I also control when it terminates so that if necessary it can
deregister itself. Threads don't just disappear unless the application
itself is being unloaded or an exception occurs that cannot be handled by
managed code (e.g. ExecutionEngineException, stack overflow, hardware
failure, etc).

Besides, I question the usefullness of using a simple thread id to control
debug output - it would never capture transients, such as code executing in
a callback from a threadpool because these types of threads come and go
seemingly at random. It would make more sense to capture output based on a
class of thread or an a transaction basis.

Perhaps, but I can't see that my simple system would fail any
requirements that yours would succeed for.

I didn't say it would - you said mine wouldn't work, and it does within the
constraints of how I intended it to be used.

(Yes, you then need to occasionally remove all the mappings which have
a WeakReference where the enclosed reference has been collected, but
that's simple.)

Thus increasing the complexity of the system. Moving the complexity from one
area to another does not eliminate it.

It just seems to create an unnecessary weakness in the system.

I don't think so, but I think we will have to agree to disagree.

 

[Jon Skeet]

Nope. Since I've already stipulated that I control the thread that registers
itself, I also control when it terminates so that if necessary it can
deregister itself.

Ah - you didn't say that was necessary in your more recent description
of your scheme:

<quote>
If all that is needed is a simple pass-fail decision based
on thread id then *all* that is needed is for the thread to register
that when the thread is created.
</quote>

Note that the emphasis on "all" is yours, not mine. If you'd said all
that is needed is for the thread to register when it's created and
deregister when it's finished, I'd agree - although that would then
create more placs for bugs to go wrong.

Threads don't just disappear unless the application
itself is being unloaded or an exception occurs that cannot be handled by
managed code (e.g. ExecutionEngineException, stack overflow, hardware
failure, etc).

And while that's unlikely to happen, it's another problem which just
doesn't exist with the simpler scheme of using a ThreadStatic variable.

Besides, I question the usefullness of using a simple thread id to control
debug output - it would never capture transients, such as code executing in
a callback from a threadpool because these types of threads come and go
seemingly at random. It would make more sense to capture output based on a
class of thread or an a transaction basis.

Sure - but as you've said before, we're basically guessing as to why
the OP wants this

I didn't say it would - you said mine wouldn't work, and it does within the
constraints of how I intended it to be used.

Well, yours wouldn't work as you described in the section quoted above

Thus increasing the complexity of the system. Moving the complexity from one
area to another does not eliminate it.

It would keep all the complexity in a single area, rather than in every
area where a thread is created. However, as I've said before, I think
the ThreadStatic system is far better than the WeakReference system
anyway.

I don't think so, but I think we will have to agree to disagree.

Sure.

 

[Dave]

Note that the emphasis on "all" is yours, not mine. If you'd said all

that is needed is for the thread to register when it's created and
deregister when it's finished, I'd agree - although that would then
create more placs for bugs to go wrong.

I was also assuming that the thread was invoking a logging method in my own
code; 3rd party threads would have no way of invoking it. I've used trace
listeners and I wasn't all that happy with it; I prefer and use my own
mechanism.