Thinking about it, I guess one possible application would be a multiple-window SDI type application where you wanted several, independent top-level peers, but didn't want to start multiple processes?
Matthew -----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.
