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

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.

/Michel