Boost logo

Boost :

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-12 12:46:30

Caleb Epstein wrote:
> On Apr 11, 2005 5:58 PM, Michel André <michel.andre_at_[hidden]> wrote:
> 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.

Thanks. Yes I think its important that at least accept should be able to
be done asynchronously so accepting connections can be done on the same
thread pool as all other io. And event connecting asynch gives meaning
and is important for crawlers and the like.

>>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?

Both that and its transportable to callbacks and separate threads and
the user can elect to throw the error in his handler and do handle
exceptions instead of codes cross thread.

> 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.

This is a real can of worms I'll tell you. Suppose you have a asynch
read pending and i handling an async read and decide to close the
connection since you got a logout pack or invalid data or something. If
the handle is locked and you want to do a sync close (ie no more
notifications after close and as a part of close all pending operations
should fail) If having a lock when doing the close from within an
handler you'll have a deadlock since the pending ops cant complete with
failure. But we will have to think about how to solve this. Especially
for iocp where the os holds the buffers until the notification is
received. Maybe close shouldn't be allowed within read or write handlers
hand need to be posted separatly asynch to the dispatcher.


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