On Fri, Apr 3, 2009 at 3:02 PM, <[email protected]> wrote: > Again, Christian, thanks for your comments. I wish people would try out the > detector - so I can get feedback and improve it.
The best time to try out something like this, is of course when the problem unexpectedly arises. Unless anyone has any outstanding deadlocks they are working around, it might be hard to do this. It might be worthwhile do something along these lines: a) Check this into the Stackless Examples repository (if you have a suitable account, I can give you access). b) Edit the wiki there to work in the deadlock detector in the right place. c) Add a page on the Stackless wiki which addresses the topic of deadlocks. d) Work out how to best make it visible on the Stackless web site (as the wiki is a little bit of a black hole) and we'll link it in. Personally, I prefer a postmortem approach like this: http://code.google.com/p/stacklessexamples/source/browse/trunk/libraries/uthread-ccp/uthread.py#660 Place the deadlock detection at the lowest level and periodically monitor unexpected behaviour. Then when unpredictable behaviour occurs in a live situation, which is not likely reproducible in a test environment, postmortem information is available. And unpredictability in my experience, tends to be best demonstrated by as full a picture of the logic flow as possible. This means a call stack with local variables. Cheers, Richard. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
