Thread handling issue

[Paul]

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.