worker thread shutdown and Form.Invoke

[Stephen Lamb]

I have a background worker thread which I start from a form's HandleCreated
event that makes calls back to the form using Invoke. During shutdown the
form is disposed and the background worker thread is aborted by the system.

How is one to keep the background thread from calling form.Invoke after the
form's window handle has been destroyed? This is definitely happening in my
application. I haven't read anything about this problem in old postings or
on the web. If this shouldn't happen and I'm doing something out of the
ordinary to cause this, could someone please explain why it doesn't happen
in the normal case. Thanks in advance.


If this helps, the worker thread is reading data from a TCPClient object
using the blocking Read method. The worker thread may also execute unsafe
code to process the data from the TCPClient object. Updating the UI with
information read off the TCPClient object is the worker threads only job.
So, it can abort as soon as the form goes away. The main UI thread is not
the thread which spawned the application but it is the one and only
non-background thread. The main UI thread is created before the worker
thread.

If no one has seen or heard of this problem, I'll try to write a minimal
demonstration of the problem and post the code.

Thanks,
Steve

 

[Jon Skeet [C# MVP]]

I have a background worker thread which I start from a form's HandleCreated
event that makes calls back to the form using Invoke. During shutdown the
form is disposed and the background worker thread is aborted by the system.

How is one to keep the background thread from calling form.Invoke after the
form's window handle has been destroyed?

With care... it's something that I've noticed being entirely missed by
every article on threading that I've seen, and I haven't found a decent
answer to it yet, to be honest.

For a "most of the way" answer, you can give the form thread-safe
methods which do the invocation internally, and which check for a flag
before doing the invoke, returning without doing it if the form has
been closed. The flag is set in Form.Closing. I believe that still
leaves a race condition, however, and I don't know enough about the
details of the underlying message queue to know how best to sort it

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Hi Stephen,
The best is to stop the thread yourself when the form closes. However
Control.Invoke won't file if the control has handle created. So
Control.IsHandleCreated gives us that piece of info, but we may go into a
racing situations. The handle is destroyed during disposal of the form. So
overriding Dispose method and using some flag should be possible to solve
that problem.The other possible points where the handle can be destoryed are
DestroyHandle (which is virtual and can be overriden) and RecreateHandle
(which unfortuanately is not virtual), but those two are protected so they
are not supposed to be called from outside.

 

[William Stacey [MVP]]

Make sure you close the thread down before closing the form (i.e. in the
Closing event, etc.), and the Worker.Stop() method should handle socket
shutdown, etc. You should not leave closing event method until the
thread(s) are stopped.

 

[Stephen Lamb]

Make sure you close the thread down before closing the form (i.e. in the
Closing event, etc.), and the Worker.Stop() method should handle socket
shutdown, etc. You should not leave closing event method until the
thread(s) are stopped.

Your solution seems simple but when I think of implementing it, I always get
either a race condition or deadlock.

My worker thread calls back to the UI thread when errors occur, if this
makes a difference. If this is not the right way to do it, could you point
me that way?

Any chance you could flesh out the detail of your solution?

Thanks much for the input.

 

[William Stacey [MVP]]

We would be happy to help. I think the easiest way to do that is if you
post some code. Can you produce a small but complete sample the shows the
issues?