From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-08-15 17:51:25
--- Jose <jmalv04_at_[hidden]> wrote:
> Given the rationale in the papers I understand that your library
> provides a multiplatform async network io solution (emulating async
> behaviour in Linux via select-like mechanisms) but that it will be
> able to include true async network aio_ calls when these are
Yep, that's it pretty much exactly.
> 1) Is this a solution that will incorporate async disk io in the
> future by wrapping the POSIX aio_ interface or just network focused ?
> (i.e. boost::net vs boost::aio)
That's why I called the library "asio" (== ASynchronous I/O) rather
than something something based on network/socket ;) Seriously, sockets
were implemented first because that's what I needed first, but I think
any OS resource that lends itself to asynchronous I/O is worth
> 2) Shouldn't the host resolver interface wrap the system getaddrinfo
> calls so that it is IP6 ready as well ( should IP6 be a priority or
> just making the sure the design is able to accommodate it easily when
> necessary ?)
Yes, although in the current design this would be
asio::ipv6::host_resolver. I think IPv6 is probably important, but I
personally have no experience with it.
> In Linux, shouldn't the host resolver wrap the native async
> getaddrinfo_a for best performance ?
I wasn't aware of such a function, and will investigate it.
> 3) How can the library tap into the ideas/experience of the other
> library users ? E.g. the nanostream library has some work that might
> be complementary.
> [... HTTP and nanostream ...]
Yep, I agree, it would be worth revisiting the other libraries that are
out there to see if there are ideas to help refine the design.
> Finally, it would be nice if in addition to your TODO list you can
> provide some document that explains the current design decisions
> (e.g. how you use threads,,..) beyond what is in the proactor pattern
Over the next few weeks I hope to write some short web pages about each
of the major design decisions taken (and some that still need to be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk