On Wed, 2008-04-09 at 01:51 +0200, Henrik Nordstrom wrote: > tis 2008-04-08 klockan 12:55 -0600 skrev Alex Rousskov: > > BTW, if somebody commits that patch, please polish the reason phrase in > > the cancel() call to something more specific. > > The submitted pach didn't work for two reasons. In fact this > cancellation of comm scheduled calls doesn't work at all. > > a) There was no cancellation of the requested event in the > IdleConnList::read or ::timeout methods. > > b) Even after fixing that it fails for pending comm calls as the > registered callback was reset when comm scheduled the callback.
I do not quite understand (b). If (a) canceled all comm calls, why pending calls are important? > and third > > c) commSetTimeout didn't cancel pending callbacks. But due to 'b' it > can't.. > > > Why: Because when comm shedules the callback it also clears the > reference, so there is no handle left to cancel it.. 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. 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. If that is the problem you are trying to solve, then you can make comm special and cancel its own pending calls. This will be ugly because comm does not know whether the call is still pending (or perhaps being handled at this very time!) and because the general code may assume that once you call you will not want to go back and do something with the call. 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). HTH, Alex.
