Steve Huston wrote:
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
Steve,
Yes, I think that is fine for a first pass. Andrew is also working on an
Infiniband DMA
async IO layer avoiding both working on that layer would be the way to go.
So as long as the select-based work maps to the async classes I am fine
as we can test the
performance and see if the extra work is warranted. the key is that we
want to retain the async
IO interfaces in the broker as they will be used for DMA based IO on 10G
and IB.
make sense?
Carl.
