wxPython and threading issue

[Patrick Smith]

Hi,
I'm hoping someone here will be able to help as I've been struggling with
this problem for a few days now.

I'm working on an application that is creating a ProgressDialog, and then
creating a thread that runs a function from another module in the program.

The problem is, when the cancel button on the ProgressDialog is pressed, the
thread that was created continues to run. How can I make it so that when
the cancel button on the dialog is clicked, the spawned thread dies?

thanks

[sjdevnull]

Patrick Smith wrote:

Hi,
I'm hoping someone here will be able to help as I've been struggling with
this problem for a few days now.

I'm working on an application that is creating a ProgressDialog, and then
creating a thread that runs a function from another module in the program.

The problem is, when the cancel button on the ProgressDialog is pressed, the
thread that was created continues to run. How can I make it so that when
the cancel button on the dialog is clicked, the spawned thread dies?

Have the main thread set a flag telling the worker thread to exit, and
have the worker thread check that periodically when it knows it's in a
safe state to exit.

[Patrick Smith]

Hi,
Thanks for your reply.

<sj*******@yahoo.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

Patrick Smith wrote:

Hi,
I'm hoping someone here will be able to help as I've been struggling

with

this problem for a few days now.

I'm working on an application that is creating a ProgressDialog, and

then

creating a thread that runs a function from another module in the

program.

The problem is, when the cancel button on the ProgressDialog is pressed,

the

thread that was created continues to run. How can I make it so that

when

the cancel button on the dialog is clicked, the spawned thread dies?

Have the main thread set a flag telling the worker thread to exit, and
have the worker thread check that periodically when it knows it's in a
safe state to exit.

This would work, unfortunately, the thread that it spawns calls a function
in a loop, that function has an incredibly long run-time, on the order of
minutes (possibly hours depending on the input), and that function, its self
is multithreaded.
This means that the worker thread could only check the flag after each
completion of this long-running function.

Given that this is the situation, is it possible to do what I mentioned
above? Or does the long running function prevent any nice way of doing
this?

[Steve Holden]

Patrick Smith wrote:

Hi,
Thanks for your reply.

<sj*******@yahoo.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

>>Patrick Smith wrote:

>>>Hi,
I'm hoping someone here will be able to help as I've been struggling

with

>>>this problem for a few days now.

I'm working on an application that is creating a ProgressDialog, and

then

>>>creating a thread that runs a function from another module in the

program.

>>>The problem is, when the cancel button on the ProgressDialog is pressed,

the

>>>thread that was created continues to run. How can I make it so that

when

>>>the cancel button on the dialog is clicked, the spawned thread dies?

Have the main thread set a flag telling the worker thread to exit, and
have the worker thread check that periodically when it knows it's in a
safe state to exit.

This would work, unfortunately, the thread that it spawns calls a function
in a loop, that function has an incredibly long run-time, on the order of
minutes (possibly hours depending on the input), and that function, its self
is multithreaded.
This means that the worker thread could only check the flag after each
completion of this long-running function.

Given that this is the situation, is it possible to do what I mentioned
above? Or does the long running function prevent any nice way of doing
this?

If the function is a black box then you are stymied, I suspect.

Had you considered using a sub-process instead of a thread to perform
the lengthy computation?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[sjdevnull]

Patrick Smith wrote:

Hi,
Thanks for your reply.

<sj*******@yahoo.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

[Re: cancelling a worker thread from the GUI thread]

Have the main thread set a flag telling the worker thread to exit, and
have the worker thread check that periodically when it knows it's in a
safe state to exit.

This would work, unfortunately, the thread that it spawns calls a function
in a loop, that function has an incredibly long run-time, on the order of
minutes (possibly hours depending on the input), and that function, its self
is multithreaded.
This means that the worker thread could only check the flag after each
completion of this long-running function.

Given that this is the situation, is it possible to do what I mentioned
above? Or does the long running function prevent any nice way of doing
this?

Well, the problem is that you can't simply kill a thread--it shares
memory with other threads that it could be leaving in an inconsistent
state. Imagine that it was, say, holding a lock when it was forceably
killed. Now any other thread that tries to acquire that lock will
block forever.

You really do need the thread's cooperation so that it only exits when
everything is in a kosher state. Can you dig into the incredibly long
function and change it to do the flag-checking and exiting safely?

I second the notion to consider using subprocesses instead of threads;
that's almost always a good idea unless you're really sharing a lot of
complex data structures.

[Nick Vatamaniuc]

If your thread is long running and it is not possible to easily set a
flag for it to check and bail out, then how does it display the
progress in the progress dialog. How often does that get updated? If
the progress dialog is updated often, then at each update have the
thread check a self.please_die flag, for example, and break out
(possibly after releasing some resources...).
Having the work done in an external process might or might not work
easily for your problem. It will make it easy to kill the execution but
it might be OS dependent, and you will have to define some
communication interface between your processes (for example, how would
an external process easily provide progress feedback to its parent?).
Patrick Smith wrote:

Hi,
I'm hoping someone here will be able to help as I've been struggling with
this problem for a few days now.

I'm working on an application that is creating a ProgressDialog, and then
creating a thread that runs a function from another module in the program.

The problem is, when the cancel button on the ProgressDialog is pressed, the
thread that was created continues to run. How can I make it so that when
the cancel button on the dialog is clicked, the spawned thread dies?

thanks

[Patrick Smith]

Well, the problem is that you can't simply kill a thread--it shares

memory with other threads that it could be leaving in an inconsistent
state. Imagine that it was, say, holding a lock when it was forceably
killed. Now any other thread that tries to acquire that lock will
block forever.

You really do need the thread's cooperation so that it only exits when
everything is in a kosher state. Can you dig into the incredibly long
function and change it to do the flag-checking and exiting safely?

I second the notion to consider using subprocesses instead of threads;
that's almost always a good idea unless you're really sharing a lot of
complex data structures.

Hi,
Thanks again for your replies.

The way this was originally working was actually using a subprocess,
however, the people who this program is for were having problems that when
the application was closed, the subprocess was still around in the system,
which was why they wanted the other module it is using to have a function it
could call, rather then using popen on the main method.

Also, the people who I am doing this for need something ASAP and for now are
fine with the cancel button completely closing the entire program. Is there
at least a nice way to do this?

Thanks for all your replies,they've all been very helpful.

[Patrick Smith]

"Nick Vatamaniuc" <va******@gmail.comwrote in message
news:11**********************@c28g2000cwb.googlegr oups.com...

If your thread is long running and it is not possible to easily set a
flag for it to check and bail out, then how does it display the
progress in the progress dialog. How often does that get updated? If
the progress dialog is updated often, then at each update have the
thread check a self.please_die flag, for example, and break out
(possibly after releasing some resources...).
Having the work done in an external process might or might not work
easily for your problem. It will make it easy to kill the execution but
it might be OS dependent, and you will have to define some
communication interface between your processes (for example, how would
an external process easily provide progress feedback to its parent?).

Hi,
The external process was their original approach, but when cancel was
pressed or the UI was closed they found the subprocess still around. Also,
it must work on windows, linux, and mac.

thanks.

[sjdevnull]

Patrick Smith wrote:

Well, the problem is that you can't simply kill a thread--it shares
memory with other threads that it could be leaving in an inconsistent
state. Imagine that it was, say, holding a lock when it was forceably
killed. Now any other thread that tries to acquire that lock will
block forever.

You really do need the thread's cooperation so that it only exits when
everything is in a kosher state. Can you dig into the incredibly long
function and change it to do the flag-checking and exiting safely?

I second the notion to consider using subprocesses instead of threads;
that's almost always a good idea unless you're really sharing a lot of
complex data structures.

Hi,
Thanks again for your replies.

The way this was originally working was actually using a subprocess,
however, the people who this program is for were having problems that when
the application was closed, the subprocess was still around in the system,

Have the main process kill the subprocess when it exits; this should be
fine unless you use kill -9 or the windows equivalent (e.g terminating
from the task manager), in which case you can kill the subproc manually
as well.

Also, the people who I am doing this for need something ASAP and for now are
fine with the cancel button completely closing the entire program. Is there
at least a nice way to do this?

maybe os.abort or os._exit depending on what you want and how they
behave on your platform?