By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,235 Members | 1,008 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,235 IT Pros & Developers. It's quick & easy.

wxPython and threading issue

P: n/a
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
Sep 29 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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.

Sep 29 '06 #2

P: n/a
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?
Sep 29 '06 #3

P: n/a
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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Sep 29 '06 #4

P: n/a
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.

Sep 29 '06 #5

P: n/a
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
Sep 29 '06 #6

P: n/a
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.
Sep 29 '06 #7

P: n/a

"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.
Sep 29 '06 #8

P: n/a
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?

Sep 29 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.