Thread Problem

Dave Sexton wrote:

Hi Brian,

Good point about volatility, however the variable is pointless anyway. It
won't allow the OP to control the background thread.

The only way to stop the _listener.AcceptTcpClient method from blocking is
to call _listener.Stop(), which will cause an exception to be thrown and the
variable won't be checked.

BeginAcceptTcpClient cannot be stopped gracefully either. Calling
_listener.Stop() will cause an exception to be thrown as well.

The OP should write code to handle this exception and exit the background
thread, as in my example.

Dave Sexton

Dave,

Good point. It seems that cancelling socket operations is a common
question. In the past I've specifically seen people ask about
cancelling the BeginRead method on a Socket. It's not obvious that you
have to actually close the socket. I remember being confused about it
several years ago when I did my first socket application.

Brian

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/li...42269.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/li...41547.aspx

Dave Sexton

"Brian Gideon" wrote in message
news:

Dave Sexton wrote:

Hi Brian,

Good point about volatility, however the variable is pointless anyway.
It
won't allow the OP to control the background thread.

The only way to stop the _listener.AcceptTcpClient method from blocking
is
to call _listener.Stop(), which will cause an exception to be thrown and
the
variable won't be checked.

BeginAcceptTcpClient cannot be stopped gracefully either. Calling
_listener.Stop() will cause an exception to be thrown as well.

The OP should write code to handle this exception and exit the background
thread, as in my example.

Dave Sexton

Dave,

Good point. It seems that cancelling socket operations is a common
question. In the past I've specifically seen people ask about
cancelling the BeginRead method on a Socket. It's not obvious that you
have to actually close the socket. I remember being confused about it
several years ago when I did my first socket application.

Brian