Hi Andrew, Thanks for your reply and willingness to help.
> Your analysis of the network IO code is basically correct - > it is based > on a Proactor pattern (implemented using a Reactor) and the essential > platform portability is intended to be through reimplementing > the Poller > class for each different platform (with the only current Poller being > based on the Linux epoll) > > However although this is conceptually the case in practice I'm fairly > sure it's not that portable yet. Right... The reactive pieces are coupled into the proactive pieces, which complicates the effort of doing a plain proactive solution. For example, AsynchAcceptor has a DispatchHandle member that assumes it'll be the target of reactive-style callbacks. The AsynchIO class is better, interface-wise. > Basically there are a bunch of different intercept points for network > IO: > The most basic of these is in replacing the top level Acceptor for the > broker end, and Connector for the client end. We can discuss this > further if you'd like (I'd have to go through the code again > in any case just to be sure I remember it correctly). Right... I'm looking closer at that now. > Ideally in porting to Windows I think you should just be able > to replace > the EpollPoller with a windows based class. Doing it with > select should > be fairly straightforward though there are a couple of things. In > particular the Poller class interface assumes that you can > change the fd > set at any point - even when you are waiting for something to > happen. This is not a problem. > It > also assumes that it is safe to wait for the next event in multiple > threads simultaneously and the returned events are fairly distributed. This one is harder ;-) > Anyway, I'm very happy to help you, so feel free to get in touch. After a weekend away from this, I'm leaning back toward taking a shot at doing the proactive implementation on Windows. I'll get back to you as I make some more progress, or hit a wall. Thanks, -Steve
