From: Jose (jmalv04_at_[hidden])
Date: 2005-12-31 05:23:44
On 12/30/05, Giovanni P. Deretta <gpderetta_at_[hidden]> 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
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
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
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
and what are the key ideas that asio has that provides a good async
I think your advanced knowledge of the topics does provide key insights for
asio to be truly
useful. I enjoyed reading your review !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk