Thread handling issue

[Paul]

Tim Golden <mail <at> timgolden.me.uk> writes:

> 
> On 07/10/2011 11:15, Paul wrote:
> > 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.
> 
> Well a lot depends on how you're doing things. (ie "It Depends"). You
> could generate an event for each thread so a second thread started while
> the first was running down wouldn't cause confusion. It's not clear
> whether the data object is common to all threads -- in which case
> you need to make sure you're locking etc. -- or is a new instance
> for each thread.
> 
> I did try a couple of passes at a code-sketch, but there are too
> many unknowns to do justice to it. Basically, have the thread poll
> an event as it moves through. Have the UI set the event and join to
> the existing thread (ie wait for it to finish) and then fire off
> a new one. Or -- if the data items are independent -- fire off
> the new one regardless and let the old one die when it sees its
> event, assuming that the data object it's populating is disposable.
> 
> TJG

Yea currently I create a new data object for each thread. I could make it a bit 
smarter and if the user goes back makes a change I could re-use the old data 
object and modify it but currently I'm not going to worry about that.

I think I'll wait for the user to actually make a change after cancelling the 
output selection, in case they go straight back without making changes. If they 
make a change I think I'll try what you suggested and send off a new thread, and 
send an event to the previous thread. Would this mean I'd need to use 
wx.lib.newevent.NewCommandEvent() to get a new event for each thread I create? 
and I'd have to pass the second return value from that, the event binder to the 
thread to bind to a clean up and exit method?