Thread handling issue

[Tim Golden]

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