For the past few days I’ve been working on a solution to a problem in WinForms. Most people are not aware of the following:
The “threading api” methods of the Control class are not thread safe. This includes calls to InvokeRequired, Invoke, BeginInvoke, and even EndInvoke. What do I mean by “not thread safe”? The worst offender is that a call to Invoke(), BeginInvoke().AsyncWaitHandle.WaitOne(), or EndInvoke() may never return control to the calling thread. This can happen when the control your calling this upon is actively in the DestroyHandle() routine at the time your thread calls these APIs. Additionally any of these calls can, if the control’s thread is actively in DestroyHandle, recreate the control on your thread. This can cause strange exceptions/behavior on the original control’s thread.
The solution is not an easy one. I built a few test cases to produce these issues and set out to solve it. Now, after a few days, I can finally put this to rest. I’ll try to include this in the next Library build, but until then the solution and more information on the issues are available here:
Avoiding the woes of Invoke/BeginInvoke in cross-thread WinForm event handling?
<rant>
And thanks for playing Microsoft but you FAIL. Threading APIs that are not thread safe… you kill me. Maybe they’ll fix it .Net 10.0 sp3 after they finish making it so that we can write a whole program on line of code. Maybe they could quit adding syntactic sugar and fix what they already have in the next release.
</rant>
(Wew, I needed that)
Update: Another reasonable answer posted today on stackoverflow.
Trackbacks