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? -- http://mail.python.org/mailman/listinfo/python-list