Hi Richard: --- On Fri, 4/3/09, Richard Tew <[email protected]> wrote:
Sorry for being so tardy in responding. And thanks for the helpful feedback. > 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. Well from reading this mailing list, I have seen a few examples of developers complaining about deadlock. So deadlock does happen. The problem is recognizing it. It would help if I had more examples other my own. I am still trying to figure out the limits of my approach. I want to punch holes in the detector. > It might be worthwhile do something along these lines: The semester ends soon so I can do most of this. Also I would need an account. > Personally, I prefer a postmortem approach like this: http://code.google.com/p/stacklessexamples/source/browse/trunk/libraries/uthread-ccp/uthread.py#660 I find this URL very helpful. I haven't played with frames and traceback so I found the example helpful. Yes, it is useful to give stuff like the line number. This may also get me into looking at debugging. > 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. I am not sure what lowest level means.... Well the way the detector currently works is that it runs once the Stackless Scheduler has decided there is deadlock. Perhaps a more obtrusive detector could wrap channels, hook into schedule.call_back, execute and throw an exception. However I doubt if this is much better. I feel, provided the detector works on all but the most trivial examples, and one is scared of deadlock, the programmer will throw in the few extra lines of code (registerResources). > And unpredictability in my experience, tends to be best > demonstrated by as full a picture of the logic flow as possible. Yes I agree. Let me play with this. >This means a call stack with local variables. Well the detector as it stands, ought to tell you about the contentious channels involved in the deadlock. I suspect analysing the local variables will give you all the channels available to the deadlocked tasklet. This is more than you may need. Thanks for the suggestions. Cheers, Andrew _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
