Re: async-calls and Dispatchers

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.

-Rob

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