Hi Carl, > > Just wondering if one of our C++ specialists would be > willing to opt in to > > work with Steve getting started on this piece ? > > > > > Sure, I will start. For M2.1 it should be quite easy to get it going, > yea there will be a > smattering of updates required for Windows. One thing to note is that > the trunk has > moved on quite a bit from M2.1, so when you get to trunk, I > am not sure that you will > be able to forward merge any of the C++ M2.1 work.
FYI, for others, Carl and I later agreed that working on the trunk would be most beneficial. > On the trunk, the IO has been written more specifically for > each, posix, epoll, etc, (provides better / more fair > scheduling and faster IO) so there are about 3 classes that > need to be cloned and re-implemented > for Windows. When you get there shout and I or someone else can point > you in the right direction. Andrew > is also a good one to ping on all the IO stuff I've been studying this area and what I see is that the code is written for a select/reactor-type demux/dispatch scheme. When I saw AsynchIO-named classes, I thought it may be possible to use overlapped I/O on Windows, which would be more efficient and scalable. However, this effort is quite a bit more work than doing a select-based implementation for Windows. I'm leaning toward doing a select-based Windows implementation to get this going since doing a real asynch I/O version "correctly" will mean some restructuring of classes and such to properly isolate the things that change from select-based to asynch-based. If I can justify the effort to do that restructuring at a later time, I'll do that. But for now, I need to get something going to do a prototype/proof-of-concept thing in the short term. Sound good? Is there any other effort going on in this area which may affect this decision? Thanks, -Steve
