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