Metal76 wrote:
I feel a little uneasy to use exceptions to implement normal programming logic, but I could not find a "clean" way to forcibly shutdown sockets
Hi Andrea, I'd love to find a cleaner method, but I haven't, which is why I do it that way :) I do include comments in my callback delegate code to remind me that certain exceptions are expected during shutdown. My server code was ported from C++, where I used an IO completion port. The same problem existed there, except the function used by the completion handler threads to wait for a completed IO (GetQueuedCompletionStatus) would indicate an error instead of throwing an exception. I still used the queuedIOcount there, because I wanted to wait for all pending IOs to be flushed from the completion port at shutdown before continuing. I'm pretty sure .NET's asynchronous IO uses IO completion ports as well, or the equivalent. The difference is, .NET handles the pool of threads for you where in straight Win32, one has to handle that manually. From everything I've seen, they chose to implement the shutdown as an exception instead of using an error code. I guess an error code could have been added to the IAsyncResult, but it wouldn't have been generic - IAsyncResults are used for more than just socket accepts and receives. Instead, the specific "Endxxxx" method documentation specifies the exception that will be thrown in error conditions. For example, Socket.EndReceive() states "ObjectDisposedException...The Socket has been closed". I don't see an alternative. The whole idea of asynchronous IO is "fire-and-forget". Once you call "Beginxxxx", the IO request is out of your hands until completion. They chose to implement exceptions instead of error codes - you don't get anything else to work with AFAIK :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
