Your code:
Public Sub startThread()
Dim t As New System.Threading.Thread(AddressOf someObject.someSub)
t.Start()
End Sub
You are getting a reference to a subroutine that happens to be in someObject. someObject will have no way to know that this method has been called as a worker thread outside of an object. Because of that you will be forced to stop the thread yourself. Abort is a sledgehammer. If someSub is written properly there should be a way to make the thread exit gracefully and then there is no need to Abort.
Public Sub Dispose() Implements IDisposable.Dispose
someObject.Dispose()
End Sub
Because someObject wasn't responsible in the creation of the thread (it had one of its methods used as a thread) it doesn't bear a responsibility in its termination. So in the design pattern you have someObject.Dispose()
won't be able to terminate the thread. You'll have to do it yourself.
If you have the ability to change someClass a proper design pattern would be to create a new method like startThread
. t
would be a member variable in someClass. startThread would in turn do something like:
t = New System.Threading.Thread(AddressOf Me.someSub)
t.Start()
Now someClass was responsible for the thread creation so in someClass's Dispose method you would attempt to stop the thread (hopefully with more grace than Abort.