[boost] Re:Asynchronous I/O

From: Don G (dongryphon_at_[hidden])
Date: 2005-03-17 11:34:43

Hi Boris,

Looks like some good research! I don't have lots of time just now,
but let me try to give you my take on this problem.

> Now who has an idea how the asynchronous C++ library
> should look like? ;)

I can only say this: how async I/O is accomplished will depend on
platform, and sometimes that is a run-time result (ex: Win 9x vs.
NT). All the various techniques you've mentioned have non-portable
aspects to them (signals are *nix only, completion ports are NT only,
AIO is a mixed bag, etc.), and as such a simple encapsulation of any
of those mechanisms will also be either non-portable our
unnecesarrily inefficient as it maps one set of semantics to another.

I think we should start by asking a different question: can we write
a portable asynchronous delivery mechanism? Answer: yes. We would
have to define what is a "message" (my choice is a function<void ()>
object), how is it queued and how is the queue drained. There are
other picky details, but that's the start.

Given such a mechanism, each type of object can provide a simple
interface for calling a function<> on completion. As I said in
previous posts: this completion callback should be free-threaded but
a simple means to supply an auto-queue-callback as a callback should
be provided.

The reason that each type of object has to provide the async I/O
implementation is that the object type is important to how one does
async I/O on some platforms (ex Windows). We can present base classes
with virtuals or just isomorphic methods, but this issue is
unavoidable. Async file I/O on Windows (NT anyway since 9x cannot do
it) is _not_ the same as async socket I/O.

Under the covers, there may be great deals of common code that is
mostly portable. For example, "select() + thread pool" can be used to
implement async I/O on Windows, *nix and Mac OSX. It may not be
optimal on Windows NT, or any particular flavor of *nix where poll()
may be available, but it will work.

Anyway, all of these things are implementation issues. A good
starting point is a design of an async network I/O interface, along
with what async delivery in general looks like. Neither of these
should be overly effected by the various OS facilities available to
implement them. Ccannot resist here: sockets are also just a
mechansim that might not be everywhere you want to go <g>. Seriously,
though, on Mac OS9 and older, there were various non-socket API's to
do networking. I can only imagine what else may be out there.

Best regards,
Don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com