> 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.
