Re: async-calls and Dispatchers

On Fri, 2007-12-21 at 03:31 +1100, Robert Collins wrote:
> On Thu, 2007-12-20 at 08:58 -0700, Alex Rousskov wrote:
>
> > > Can I ask why? The point of the current design is to allow integrating
> > > some quite different sources of events *and* workers.
> >
> > CompletionDispatcher was documented as "code to handle events that have
> > completed". It was implemented as an abstract "call me once per main
> > loop iteration" interface. We already have AsyncEngine class for that
> > (the purpose of AsyncEngine class is not really documented so I am
> > judging by the code).
>
> Have you read the ACE patterns for event handling? I'm really just
> grabbing a glass of water before going back to sleep (its 3am :)), so
> this isn't a full reply, and essentially reading the two key patterns
> they published - reactor and proactor - will give you the design which
> was an application of those patterns to our current code base at the
> time I wanted to clean up the event loop.
>
> The difference between engine and dispatcher was intended to decouple
> 'perform X concurrently' (an engine), and 'handle the result from a
> given engine'.
>
> Engines were called once per loop to handle pseudo-async engines that
> are not really asynchronous and thus need a time-slice to operate.
>
> Dispatchers are called once per loop to allow for synchronisation where
> that is appropriate - such as with OverlappedIO.
>
> 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.

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.

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.

HTH,

Alex.
[1] http://www.artima.com/articles/io_design_patterns2.html
Received on Thu Dec 20 2007 - 10:05:05 MST