I entirely agree with that approach. The reason I suggest that it is rude in the case where you are spinning work off onto a pool thread is that the pool thread didn't have a message queue when you were given it, and there is no way of clearing it up afterwards, so you haven't left things as you found them wrt to the pool's thread context. I think that's faintly rude!
Matthew Adams -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Chris Sells Sent: 29 May 2002 16:10 To: [EMAIL PROTECTED] Subject: [DOTNET] Putting bits of UI on a secondary thread? (was Re: [DOTNET] Modeless WinForms Bug) > As an aside, a quick experiment reveals that all appears to be fine if > you start the message pump on the worker yourself (with > Application.Run()), but it is still slightly rude, as that pool thread > will then have a message queue created for it that may not have existed > before. I don't know why that's rude. No thread has a message queue until someone starts looking for or posting messages, even the main thread. It would be more rude if a console app had a message queue w/o ever needing one. I've had no problems running different bits of a UI on multiple threads, so long as I obey the rule of thread affinity for controls, but I have yet to find a reason to put bits of UI on anything but the main thread. Since the UI operations are already segmented carefully into little bits of work in event handlers, I haven't yet been able to motivate the need to have UI running on secondary threads. My prefered model is to spin off long running operations onto threads from the thread pool via asynch delegates and use message passing between the UI thread and the worker threads to communicate work/results and eliminate the need for synchronization. Chris You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
