tis 2008-04-08 klockan 07:47 -0600 skrev Alex Rousskov:
> I believe there is a better option that was added to handle specifically
> to handle these kind of problems:
>
> d) Cancel the call when it is no longer expected.
That's also an option, not at all far from 'a'.
> This is already supported by AsyncCall::cancel() but the old code needs
> to make use of it..
Good. Didn't know that.
So any proposals on how we would go about fixing comm_read_cancel?
Hmm.. on reading that code commio_cancel_callback looks a bit odd in
trunk. Why is callback set to NULL twice, and what is really the purpose
of this function now that the actual callback is in an AsyncCall..?
Is it perhaps as simple as making commio_cancel_callback call
ccb->callback->cancel()? Testing.. seems to work. Patch attached. Any
comments?
Most of the AsyncCall code is still a bit alien to me, just starting to
unwind it...
> Canceling a call requires a pointer to the call,
The Call is known from what I can tell..
> Option (d) is similar to (a), but does not require rewriting AsyncCalls
> and is more explicit/direct, which may help developers with using it
> correctly.
'a' doesn't require any change in AsyncCalls.
> It is an open question whether low-level interface like comm may
> cancel
> calls implicitly (i.e., when something happens to FD state and not as
> a
> result of an explicit comm_cancel_* call).
In most cases the object then goes away, making cbdata trap the call.
Regards
Henrik
This archive was generated by hypermail 2.2.0 : Wed Apr 30 2008 - 12:00:07 MDT