Re: [boost] async socket i/o [long]

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-04-11 23:14:00

On Apr 11, 2005 5:58 PM, Michel André <michel.andre_at_[hidden]> wrote:

> There has been some discussion on this on the list lately. Is there
> anyone working on it. I have been pondering an interface that supports
> both async and blocking io combined. And an event dispatching model that
> can handle several types of dispatching mechanism through a the same
> interface to provide for a lot of differnet implementations.
>
> [ proposed interface ]

Looks very nice.  Simple design, with what looks to be a complete
interface and plenty of room for plugging in platform-specifics.  I
like the attention to detail: accept and connect can of course block
(can listen too?), so providing ways to call them asynchronously is a
nice touch that is lacking in some "C++ sockets" implementations.

> The io_result class is a helper class that handles reporting of the
> actual result and eventual error outcome of an operation. It combines
> error codes and exception throwing.
> 
> // encapulates a result of an net operation
> // throws an io_error if none of the following
> // members haven't been called before destruction:
> // failed,success,error_code,throw_exception.

What is the explanation for this behavior?  The user may not ignore io_results?

> So this is the outline of an interface that I think could serve as a
> foundation for a net library. I will try to go about and implement
> prototype for this using both select and iocp. But there are some things
> to iron out such as thread saftey and such (since it will necessary to
> at least having several threads blocking in dispatch_event at least the
> event_dispatcher would have to be thread safe and probably parts of the
> event source d).

Yes.  If an event_handler for a particular connection is still running
in one thread, you (probably) don't want to dispatch it again in
another thread if the underlying OS event mechanism fires again for
the same handle.

> What are your initial thaugths on this, implementatble? flexible enough?
> efficient enough?

As I said above, I like it.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com