On 12/30/05, Giovanni P. Deretta <gpderetta@gmail.com> wrote:
exported. The various reactors/proactor implementations should be removed from the detail namespace and be promoted to public interfaces, albeit in their own namespace (i.e. win32::iocp_proactor, posix::select_reactor, linux::epoll_reactor etc...). This change will make the library a lot more useful.
I agree. There was at least 1 reviewer also asking for this. I think chris has stated it won't do it but I haven't seen the reasoning
On some systems there is already an asynch resolver call (glibc provides getaddrinfo_a). Asio should use them instead of its own thread based emulation. The glibc api still use threads, but a strictly single threaded implementation is theoretically possible.
I've used getaddrinfo_a in a single user thread. Note you have to use polling becasue there is a bug with the signal interface http://sources.redhat.com/ml/libc-alpha/2005-01/msg00049.html While I didn't use all of it (No timers nor SSL), as an experiment I did
write a simple continuation library using asio::demuxer as a scheduler and using asio callback pattern to restart coroutines waiting for i/o. Asio's demuxer cleaness and callback guarantees made the implementation very straightforward. If some one is interested i may upload the code somewhere.
Please upload it. I found your code very useful to learn advanced c++
Yes, a bit. I've written my own network library, although synchronous only. I've studied the asynch problem in depth, but I've only theorethical knowledge of it. I did not add async support to my library because I couldn't find a good async interface.
Just for educational purposes, what do you mean by "I coudn't find a good async interface" and what are the key ideas that asio has that provides a good async interface I think your advanced knowledge of the topics does provide key insights for asio to be truly useful. I enjoyed reading your review ! Thanks