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