Caleb Epstein wrote:
On Apr 11, 2005 5:58 PM, Michel André <michel.andre@swipnet.se> 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