tis 2008-04-08 klockan 18:58 -0600 skrev Alex Rousskov: > In general, the caller should forget about the call after making it > (i.e., after scheduling it). We can make comm different, but I am not > sure it is a good idea from the clarity/simplicity point of view.
Which kind of rules out using cancellation as a solution to the problem as can only cancel what you know about, not things you have forgotten. I do not want to view comm different, I want to find a predictable and verifiable model in how AsyncCall should be used where it's possible to audit that things like the pconn race won't bite us. > In general, there should not be a problem with comm not canceling a > pending call unless the recipient of that call is accessing some comm > structures directly, assuming they are still valid when the handler is > called. Since nothing is immediate, such an assumption may be wrong. The above assumes each call handles cancellation itself, or that the object used by the call is invalidated and not the call itself.. > The alternative is to fix the real/core problem -- the call recipient > directly accessing state of some other asynchronous job (if that what > the problem is). The problem is how to handle cancellation of interest properly without it racing with the event you cancel having already occurred and sitting in the AsuncCall queue. The current case with the comm code is only a scratch on the surface. What I am after is to find the proper model on how AsyncCall should be used, allowing us to audit the code against this kind of races. You propsed we should cancel the call, but that model is incompatible with the model where you forget about the call when scheduling it as you then have a race where the call may already be sitting in the call queue when you want to cancel it. It's not as bad as the call recursion in the old model, but in the same family of unwanted and hard to audit race conditions. Regards Henrik
