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>.
signature.asc
Description: This is a digitally signed message part