Re: async-calls and Dispatchers

On Fri, 2007-12-21 at 04:25 +1100, Robert Collins wrote:

> The dispatcher design has a great deal to do with handing results from
> async operations, because the OS can and will call directly back into
> user code.

I am sorry, but a class with a single pure virtual method cannot have a
great deal to do with anything, especially when there is another class
that provides the same interface.

It is possible that you planned it to be something else, but those plans
did not materialize. In reality, we had two nearly identical classes
that were used nearly identically. The only difference was the timeout
setting. In practice, all those dispatchers were just a complex way to
say "call me at least once per main loop" and we already have an
interface for that.

Yes, the OS will call user code, but comm will receive such calls and
propagate them using standard async calls. There is no need to expose
the rest of Squid to these low-level details.

> Re-reading the native async calls wiki page, it seems to me that 'all'
> you need to do is implement your 'TheCalls' as a dispatcher into the
> current EventLoop. If you are not handling the os level concurrency
> interface, then a Dispatcher should be all you need.

Yes, I could have done that. However, since async calls remove the need
for all existing classes that were dispatching some events (or
pretending to do so), there is no need to build upon that unused
interface. I simply do not see any practical reason for that interface
to exist. If you can give me specific examples where the code would
benefit from the abstract CompletionDispatcher class (and should not use
the remaining AsyncEngine API), I am all ears.

> Note also that the
> current design was in the process of removing global state to make
> testing and modularisation easier, so please do take care not to
> reintroduce dependencies on global variables etc.

>From that point of view, we are essentially removing things here, not
adding new ones so modularization can only improve. As for unit testing,
if it makes the actual code a lot more complex, it is doing more harm
than good.

Alex.
Received on Thu Dec 20 2007 - 11:01:03 MST