Boost logo

Boost :

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,

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

Boost list run by bdawes at, gregod at, cpdaniel at, john at