Is Thread.Abort() blocking until Thread has exited?

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/de...ms06112002.asp

The code is in C#, but the concepts apply equally to VB.NET
--
Tom Shelton

Joe I had the same problem with a UDP socket in a thread...i had to do this
and it worked.

'Without this the thread could still remain open
receivingUdpClient.Close()
'Abort the thread - This doesnt always work alone - need to
close socket as well.
ThreadReceive.Abort()

Miro

"Tom Shelton" <to*@mtogden.comwrote in message
news:11**********************@m79g2000cwm.googlegr oups.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/de...ms06112002.asp

The code is in C#, but the concepts apply equally to VB.NET
--
Tom Shelton

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.

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 ...

Thanks!
Joe

Tom Shelton wrote:

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/de...ms06112002.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

Hello Tom -

Thanks for the info ... I will definitely give that a try and look into
the issue!

Thanks!
Joe

Tom Shelton wrote:

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

Hello Tom -

Thanks for the info ... I will definitely give that a try and look into
the issue!

Thanks!
Joe

Tom Shelton wrote:

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