>> Agreed - I hope my somewhat labor intensive DBIN DBOUT individual thread logging mechanism can help ... <<
I LOVE instrumentation, and think that it's used far too little, but from what little information we got on this problem, I didn't think that would help. First of all, it's only useful for our own code, or code that we control. Roy seems to be having problems with objects from other libraries---Other People's Code; or with the lifetime management, or configuration of those objects. Even though chances are always greatest that the error lies with us, the immediate coder, in this sort of problem we're likely to find *evidence* of the problem INSIDE Other People's Code. It is normally either impossible, too difficult, or far too cumbersome to instrument other people's code. The best we can do is instrument the "gateways" to that code, as in your example of bracketing the CallSomeProcedurethatISuspectAFail() call with your logging facilities. >From what we can see of this specific problem, 4-dimensional sleuthing and a quantum bloodhound are needed <g>, not a trail of breadcrumbs. It's more like trying to find Dr. Who's randomizing Tardis through time and space (good luck!), than hunting a sequential path... --- About your logging facilities, I'm surprised about several aspects of that code: Firstly, that you incorporated that into a TThread subclass; why not use generic logging facilities that could incorporate "global" logging, and levels etc.? Then, assuming you want some special checking to be done on matching entrances with exits, I was surprised there was no stack-checking mechanism to confirm that an "out" call is correctly matched with the last "in" call. (There's only a "bottom-of-the-stack" check for overflow; most likely because it's the easiest and cheapest--by a good margin.) Next, since this is (by "definition") *very* thread specific, you'd expect the code to try to have a minimum footprint, so as to affect thread timing and other such issues as little as possible. One would expect to avoid context switches as much as possible, particularly those in and out of the OS kernel. But this code not only doesn't avoid that, it makes *heavy* use of the *filesystem,* opening, writing and closing the log file on every in and out call (while apparently holding a critical section, which with this sort of activity will *often* not pass on the in-context spinlock portion, but be required to context switch to a full mutex in the OS kernel). That's expensive. Bracketing the calls with the compiler directives is also programmer-expensive, and makes code reading harder. You wouldn't really give up that much performance if you let the method calls exist even in production code with all the (few) compiler directives contained _within_ the logging-thread class. If there were _REALLY_ performance-sensitive areas of code, you could still bracket those calls with the compiler directives. Or even, "embrace" a different (boolean method) call inside an assert() call which gets stripped out of production code by the compiler... [The logging method would actually *always* return true; the function result wouldn't really be used other than to provide a value that assert needs, and that won't trigger an exception from assert().] Just some thoughts. I know it's a tool that helps, but if you get into performance and/or timing issues (not unheard of with threads <g>), some of the optimized (and flexible output, etc...) logging facilities available "out there" would offer quite a bit, both in features and performance. And the "performance" benefits, mean far better timing with threads, which adds up to much easier and more accurate debugging. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
