Hi Brian,
It was strange to me as well, at first, but it makes perfect sense now.
For one thing, if you try to cancel any asynchronous operation without the
use of synchronization objects there will be some exception thrown, whether
it's ThreadAbortException or something else. I think the lack of a
mechanism to cancel async operations in Sockets has more to do with
threading architecture than it does with the Sockets implementation. But
even in the Winsock architecture on which Sockets is built, canceling a
blocking operation results in an error, although it's allowed. This article
states how canceling any operation other than Accept or Select may render
the Socket unusable so that only Close may be called:
"WSPCancelBlockingCall"
http://msdn2.microsoft.com/en-us/library/ms742269.aspx
And check out this article too which explains how the WSACancelBlockingCall
(different from above) is now deprecated in Winsock 2.0. The article
recommends using a custom synchronization mechanism on another thread if
your application needs to be designed so that blocking calls may be legally
cancelled (although that's just my interpretation):
"WSACancelBlockingCall"
http://msdn2.microsoft.com/en-us/library/ms741547.aspx
I hope he