Boost logo

Boost :

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-31 09:12:51

Giovanni P. Deretta wrote:
> I think that the most important innovation of asio is the dispatcher
> concept and the async call pattern. Everything else is just *extra*.
> The {datagram|stream}_socket interface is nice, but i have some issues
> with them.
> Also i think there should be *no* asio::stream_socket. This is my major
> The current stream socket should be in the namespace asio::ipv4, and
> should be a different type for example from an eventual
> asio::posix_pipe::stream_socket or asio::unix::stream_socket.
> I think the interface could be extended for better efficiency (i will
> try to describe later how), but this can be done at a later stage.
> I don't really like a lot the service concept. While I agree that the
> service repository is useful to hold the various proactor
> implementations (iocp_service, reactive_service<kqueue>,
> reactive_service<epoll>, etc...), i don't think that the streams should
> care about them. As long as the impl_type are interoperable, any stream
> should be bindable with any service. This also means that the binding
> with the demuxer should *not* be done at creation time, but at open
> time. This will make it possible to have different openers: connector,
> acceptor, unix::socket_pair, posix::pipe etc. The openers are instead
> created with a demuxer reference and will pass it to the socket when
> opened. By the way, the implementation of socket functions (accept,
> connect, read, write, etc) should not be members of the demuxer service
> but free functions or, better, static members of a policy class.
Yes - I was trying to figure out how to fit that into the current
design, sounds like a good approach.
> The current interface let the user put a socket in non blocking mode,
> but there is not much that can be done with that, because no reactor is
> 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 just wanted to endorse this in the hope that your slant on it makes
more sense than mine. I think (haven't had a proper look at it to be
sure) your suggestions address my major concerns with the library.

Darryl Green.

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 30/12/2005

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