"Tom Shelton" <t**@mtogden.com> wrote in message
news:1157132538.352251.243960@m79g2000cwm.googlegroups.com...
>
> Joe HM wrote:
>> Hello -
>>
>> I have a function that calls Thread.Abort() to stop a thread in a
>> _Closed() Method of a GUI.  The thread contains a blocking call on a
>> TCP socket and that is the easiest way to stop that.
>>
>
> Except that Thread.Abort will not stop a thread in a blocking socket
> call - at least not right away.  The socket calls end up in unmanaged
> code, and so the request will not be acknowledged until the thread
> returns to managed code (see the docs for thread.abort for further
> information).
>
> The best way to stop a socket thread, is to close the socket and then
> exit the thread (this avoids the call to Thread.Abort).
>
>> This thread is also outputting strings in a RichTextBox and in some
>> rare instances I get a System.NullReferenceException when I exit the
>> GUI.  It seems like the _Closed() Method calls Thread.Abort() and then
>> continues closing down/disposing the form elements while the thread is
>> still trying to access the RichTextBox.
>>
>> I guess I might have to add some mutex or similar locking mechanism to
>> make sure that this cannot happen.  I just throught that the
>> Thread.Abort() would wait ... or doesn't it?
>
> It certainly does sound like a threading situation - but I hope you
> aren't directly accessing the RichTextBox from the background thread...
> That is a big no, no - and will most likely lead you to very
> unexpected results and crashes.
>
> This is part 1 of a 3 part article that explains thread/ui interactions
> and how to do it properly:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms06112002.asp
>
> The code is in C#, but the concepts apply equally to VB.NET
> --
> Tom Shelton
>

> Joe HM wrote:
> > Hello -
> >
> > I have a function that calls Thread.Abort() to stop a thread in a
> > _Closed() Method of a GUI.  The thread contains a blocking call on a
> > TCP socket and that is the easiest way to stop that.
> >
>
> Except that Thread.Abort will not stop a thread in a blocking socket
> call - at least not right away.  The socket calls end up in unmanaged
> code, and so the request will not be acknowledged until the thread
> returns to managed code (see the docs for thread.abort for further
> information).
>
> The best way to stop a socket thread, is to close the socket and then
> exit the thread (this avoids the call to Thread.Abort).
>
> > This thread is also outputting strings in a RichTextBox and in some
> > rare instances I get a System.NullReferenceException when I exit the
> > GUI.  It seems like the _Closed() Method calls Thread.Abort() and then
> > continues closing down/disposing the form elements while the thread is
> > still trying to access the RichTextBox.
> >
> > I guess I might have to add some mutex or similar locking mechanism to
> > make sure that this cannot happen.  I just throught that the
> > Thread.Abort() would wait ... or doesn't it?
>
> It certainly does sound like a threading situation - but I hope you
> aren't directly accessing the RichTextBox from the background thread...
>  That is a big no, no - and will most likely lead you to very
> unexpected results and crashes.
>
> This is part 1 of a 3 part article that explains thread/ui interactions
> and how to do it properly:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms06112002.asp
>
> The code is in C#, but the concepts apply equally to VB.NET
> --
> Tom Shelton

> Joe HM wrote:
> > Hello -
> >
> > Thanks for the info!
> >
> > I changed the code to not Abort() the Thread anymore but rather call
> > the Close() on the NetworkStream and then the Close() on the TCPClient.
> >  This seems to be working without a problem.
> >
>
> That's usually the easiest way.
>
> > The Thread actually calls a function outside the Thread that calls a
> > function in the Form to add the text to the RichTextBox.  So that
> > should be fine ... I will still look at that article you referred to,
> > though ...
>
> Well Joe, if the thread calls the function, then the function is
> executed in the context of the thread.  Unless you use the forms Invoke
> method, then you are probably going to end up with issues.  An easy way
> to find out is to insert a test in the function that is updateing the
> RTF box.  Just test the controls InvokeRequired property.  If it
> returns true, and you aren't using the Invoke method to update the
> control - then you have an issue.
>
> --
> Tom Shelton

> Joe HM wrote:
> > Hello -
> >
> > Thanks for the info!
> >
> > I changed the code to not Abort() the Thread anymore but rather call
> > the Close() on the NetworkStream and then the Close() on the TCPClient.
> >  This seems to be working without a problem.
> >
>
> That's usually the easiest way.
>
> > The Thread actually calls a function outside the Thread that calls a
> > function in the Form to add the text to the RichTextBox.  So that
> > should be fine ... I will still look at that article you referred to,
> > though ...
>
> Well Joe, if the thread calls the function, then the function is
> executed in the context of the thread.  Unless you use the forms Invoke
> method, then you are probably going to end up with issues.  An easy way
> to find out is to insert a test in the function that is updateing the
> RTF box.  Just test the controls InvokeRequired property.  If it
> returns true, and you aren't using the Invoke method to update the
> control - then you have an issue.
>
> --
> Tom Shelton