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

Boris wrote:

3) AIO AIO is part of the Single UNIX Specification and an official standard for asynchronous input and output. The AIO API is based on file descriptors and defines a few functions inluding aio_read() and aio_write(). I/O is asynchronous because the process is notified when an input or output operation is completed - there is either a signal sent to the process or a callback function is executed (as a thread). Further more it is possible to poll a file descriptor if the process doesn't want to wait for the signal or the callback function. Now to the disadvantages: Linux 2.6 doesn't support AIO with sockets (see http://lse.sourceforge.net/io/aio.html).

Is this current? I have been looking a little, and I'm not sure, but from some of the posts I see I think this may be fixed.

The MacOS X kernel's (XNU) BSD component has the kqueues and aio facilities. On Mar 17, 2005, at 7:08 AM, Boris wrote:

<snip> I don't know what other operating systems like Mac OS X support. There is kqueue() is their man pages (see http://developer.apple.com/documentation/Darwin/Reference/ManPages/ index.html) but I don't know if it is supported. AIO doesn't seem to be supported. <snip> Boris

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

----- Original Message ----- From: "Boris" <boris@gtemail.net> To: <boost@lists.boost.org>

1) Signal-Driven I/O SIGIO is sent to a process whenever something happens with the socket. As there are too many things happening with a TCP socket the signal is generated too often and "signal-driven I/O is next to useless with a TCP socket" (W. Richard Stevens in his network bible). As there is just one signal handler per signal it shouldn't be used in a library anyway.

[snip lovely research]

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

Good background and a little daunting. Happy to see your new subject; the change highlights the fact that issues around async sockets/networking have much broader scope. I think its appropriate to mention that typical software development is not async in nature, i.e. the picture is perhaps worse as there is a plethora of issues arising from the variety of OS async mechanisms and the global body of software developers does its best to express everything in procedural/OO terms. These two trains have to collide somewhere. Maybe I can describe this another way. It would seem logical (to me :-) to target an async I/O library that integrated cleanly with A. Hubers FSM work, with the view of implementing socket management with a Huber FSM. This follows from the belief that async software == state machine software. But what portion of Boosters would find an FSM-based "Boost socket" palatable? There is clearly a learning curve involved around Andrea's work and it has been contentious enough, without throwing sockets into the brew. This might all sound a bit gloomy but really its just creating the challenge; "can we write a portable asynchronous delivery mechanism?" (good one Don). Cheers.