Hi Christian:
--- On Wed, 4/1/09, Christian Tismer <[email protected]> wrote:
> I don't really get where the problem is. It is IMHO just fine to
>detect and analyze this first simple deadlock.
> How would you think to do more than this? The example has a
> very predictable future, because it is constructed this way.
Yes this is a simple example. What I wanted to show was when the deadlock
occurs, many of the resources (channels) that are causing the deadlock to
happen, have not been executed. So I suspect a detector based on only channel
wrapping wouldn't by able to give decent diagnostics. You have to give the
detector more upfront information.
> You are trying to predict deadlocks before executing the
> code?
No. The detector only works at runtime.
>But how should that work for any non-trivial program,
>where control flow is dependent from data and computations?
The detector ought to work for a complex example. However the detector has to
know about the tasklets and channels that can cause a deadlock before the
deadlock occurs. This is because of the hold-and-wait condition - resources
the application is holding are never reached (executed). A result is one may
get a very cumbersome detector. I want a detector that is about as cumbersome
as a logger.
Let me work on more complex scenarios.
Cheers,
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
