By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,143 Members | 1,919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,143 IT Pros & Developers. It's quick & easy.

worker thread shutdown and Form.Invoke

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Stephen Lamb <sl***@easystreet.com> wrote:
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 :(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #2

P: n/a
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.
--
Stoitcho Goutsev (100) [C# MVP]
"Stephen Lamb" <sl***@easystreet.com> wrote in message
news:10*************@corp.supernews.com...
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

Nov 16 '05 #3

P: n/a
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.

--
William Stacey, MVP

"Stephen Lamb" <sl***@easystreet.com> wrote in message
news:10*************@corp.supernews.com...
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


Nov 16 '05 #4

P: n/a
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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.
Nov 16 '05 #5

P: n/a
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?

--
William Stacey, MVP

"Stephen Lamb" <sl***@easystreet.com> wrote in message
news:10*************@corp.supernews.com...
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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.


Nov 16 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.