Yes, that would hang. You're using "Invoke" from myThread - that will
block until the delegate you've passed it has been executed on the UI
thread.
Now, from the UI thread, you're calling myThread.Join - that will
block until myThread has completed.
Ok, it's a deadlock.
I was uncertain as what happened as a result of Invoke. Thanks to
your reply, I have a better idea. The message queue in the main
thread is processing the 'stop button clicked' message, which is
running Thread.Join, which is waiting for myThread to terminate. The
message queue is stalled (never a good idea).
myThread is upset that it doesn't own the control (as it shouldn't,
since it doesn't have a message queue to maintain it), so it tells the
GUI thread to deal with it, via Invoke. Now, my understanding is that
Invoke is *not a function pointer call* (perhaps this is why they call
them delegates, instead of function pointers?), it is a message placed
in the GUI thread. (This is why an earlier post mentioned that
Control.Invoke is serialized, meaning they are handled one at a time,
because the message queue processes one message at a time. So, if
multiple threads posted multiple messages into the queue, it still
does one at a time, and my WebBrowser doesn't need a critical
section.) But, the GUI thread has its message queue stalled.
Solution #1: Use BeginInvoke, which is a 'non blocking' call (it must
call Win32's PostMessage instead of SendMessage).
Solution #2: Don't use Thread.Join(). The examples show it, so I
used it. Often, it is unneeded.
Solution #3: Don't make the worker threads access the GUI.
Solution #4: Use BackgroundWorker, which I presume doesn't have this
issue (I think it calls a function of yours when it is done, so you
never have to call something like BackgroundWorker.Join, which likely
doesn't exist).
Does that all make sense?
Zytan