You are right when you are using a BGW in a WinForm app, because you can lean on the single threaded behaviour of a message pump...
In the original example posted, the app *has* to wait for the tasks to be done, before exiting. Now waiting is best done with an event, it uses much less cpu cycles than constantly checking a variable. And since I (and others) suggested to use ThreadPool.QueueUserWorkItem, I provided a class that would work in that scenario too. // Ryan On 7/20/07, Nassar, Anthony <[EMAIL PROTECTED]> wrote:
I might be out of sync here, but isn't the GUI's sole problem, knowing whether any background tasks are running? So why can't it increment (on the main thread) the number of pending tasks when it creates one, then have the event handler for TaskDone or whatever it is decrement that number (this will also happen only on the main thread)? If the count of pending tasks is not 0, the app should refuse to exit. Only the main thread will ever access this variable, and the thread will never have to block. It should not wait on *anything.* I don't see the concurrency issues here. I do this all the time, in fact. =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
=================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
