Tim Golden <mail <at> timgolden.me.uk> writes: > > On 07/10/2011 09:29, Paul wrote: > > I'm wondering what the best solution for this problem is. > > > > I've got a wxpython app, in one part a user makes some selections then > > opens a > > dialog to select where to output. At which point the app starts a thread > > processing their selection while they're choosing an output location, hopefully > > ready for when they're done. > > > > My problem is if the user doesn't select an output location and cancels the > > dialog to go back to the selection I want to terminate the thread to avoid the > > user opening and closing the output selection firing off a ton of threads. > > > > As there's no inbuilt way of killing threads I was wondering the best way to > > prevent this? > > The most common approach is to have the thread monitor an event which is > set if, for example, the user cancels. The thread may of course have to > wait, for example, for a long-running database query to complete before > it can discover that its time has been wasted :) > > The exact mechanism will depend on how your code is structured, > what the thread is doing, and how it's passing anything back > to the main thread. > > TJG >
My first thought was to use a flag but wouldn't the new thread see the cancel flag and stop as well? I could set it back but then any other threads might have been busy and not seen it while the flag was on. The thread goes through the selection and does a few quick server calls for each one building up a data file. I guess as the server calls are quite fast the thread would be able to check flags quite often unless it's getting time-outs or something. The threads don't pass anything back they're passed a reference to a data object which is constructed before the thread starts. The thread makes updates to the data object and sets a complete attribute flag in the object before finishing. -- http://mail.python.org/mailman/listinfo/python-list
