[boost] Re: Network library: What we have until now

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-13 08:51:46

Hi Boris,

Boris wrote:
> The multiplexing interface can be used in a
> single-threaded application while the async stuff
> will be multi-threaded. There might be network
> developers (like me for example :-) who don't want
> to synchronize callbacks but just want to build
> the whole application around a blocking call to
> select (or any other multiplexing operation).

What I was trying to get at is that this can be provided by the
boost::function<> queue apporach. Possibility #1: Using the general
async library (like the one I proposed<g>), pass callbacks that have
built-in enqueue behavior. Possibility #2: A simple/single call to
the network object could tell it to queue calls to completion
handlers instead of make them immediately.

I prefer #1, but #2 would be simpler to use. The idea is that one
does not abstract an fd_set, rather one describes the target of
notification callbacks.

> Basically I like the idea to have an async I/O
> library just like std::iostreams which supports
> synchronous I/O. However I don't know how difficult
> it is to implement such a library but isn't POSIX
> aio exactly about this?

I like the idea of async I/O facilities, I just don't believe that
there can be much of an async I/O library that lies _beneath_ files,
networks, etc..

>>> * On a low level the network library should be close to
>>> what is known as Berkeley sockets to many programmers.
>>
>> I think sockets should be hidden.
>
> Opinions seem to vary on this. When I once proposed to
> build a C++ network abstraction with I/O streams I got
> complaints that it should be possible to use sockets
> directly in a lower level. Whatever you write the other
> group will join the thread and complain. :)

Agreed ;). What I have proposed does not entail iostreams, rather it
is an abstraction of primitives.

> Yes, that's why I am trying to find a design the
> majority agrees with. If we end up with several network
> libraries implemented by different people noone will do
> the effort to understand and compare design decisions.

An effort that is worth doing :)

Best,
Don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com