Re: async-calls and Dispatchers

On Thu, 2007-12-20 at 10:05 -0700, Alex Rousskov wrote:

> >
> > Expected dispatchers that are fundamentally different to each other
> > were:
> > - Standard select/epoll style
> > - Completion ports (win32) style
> > - threaded worker operation gathering
> > - deferred operations within a single thread (which is the single
> > special case I understand async-calls to be optimised for)
> >
> > So I'm curious how you will handle these.
>
> This is a theoretical question, right? In practice, we had two nearly
> identical classes that were handled nearly identically in the main loop.
> There cannot be any theoretical justification for that, regardless of
> any design patterns or future application targets.

Uhm. Which two? If you mean the abstract interface, well I don't think
they are used *that* identically; OTOH its only about 2 lines of code
for the dispatchers use by the main loop -- kindof easy to be identical
there. If you wanted to make all AsyncEngine a subclass of dispatcher
that might reduce the duplication without reducing the current
flexibility.

> On a theoretical level, the comm module should provide "proactive" async
> I/O interface to the rest of Squid code. Internally, comm should support
> both proactive async and reactive sync I/O, depending on the platform
> and configuration. See the "solution" at [1], but you probably know all
> this better than I do.

Thats roughly what I implemented in squid3. Select/poll/epoll are
emulated proactors. If/when Guido or someone else has the chance, a
OverlappedIO completion port based engine will have a paired class to
handle the OS calling back into squid. That could then pass back to your
native-async-calls for passing back up to higher levels.

> The above has nothing to do with dispatching callbacks though! It is
> about what happens before and after the callback. NativeAsyncCalls
> feature is about dispatching calls, not about I/O or threads. It will
> make support for async I/O and threads easier, I think, but it is not
> tied to any I/O or threading model.

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.

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. 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.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.