threading issue: preventing starting twice
In the threading module, one must of course only start a thread once. I have some questions about handling this gracefully. First of all, the documentation only says it is an error to start a thread more than once. It does not say which exception is raised. On my system I find it is AssertionError. So...is that going to be true on all systems? Is the test based on "assert", in which case it will go away for optimized code (and then what happens)? Anyway, if it is always AssertionError, I'd like to get the docs updated to say that. Also...if possible, it'd be nice to have some way to ask if a thread has ever been started. More generally, it'd be nice to be able to determine what state a thread is in. I'm not sure if there are any states other than ready to run, running and finished. If that's it, perhaps one could add methods isReady and didRun (a getState method would probably be better if there are more states, but then one has to deal with magic constants). I realize it is a common Python paradigm to assume something will work (such as starting the thread) and catch the exception if it doesn't, but: - this is tricky if the exception is not documented - sometimes one simply wants to know, without actually starting the thread -- Russell
On Wed, Feb 25, 2004, Russell E. Owen wrote:
First of all, the documentation only says it is an error to start a thread more than once. It does not say which exception is raised. On my system I find it is AssertionError. So...is that going to be true on all systems? Is the test based on "assert", in which case it will go away for optimized code (and then what happens)?
Anyway, if it is always AssertionError, I'd like to get the docs updated to say that.
File a doc bug. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Do not taunt happy fun for loops. Do not change lists you are looping over." --Remco Gerlich, comp.lang.python
In article <20040225194837.GA5220@panix.com>, Aahz <aahz@pythoncraft.com> wrote:
On Wed, Feb 25, 2004, Russell E. Owen wrote:
First of all, the documentation only says it is an error to start a thread more than once. It does not say which exception is raised. On my system I find it is AssertionError. So...is that going to be true on all systems? Is the test based on "assert", in which case it will go away for optimized code (and then what happens)?
Anyway, if it is always AssertionError, I'd like to get the docs updated to say that.
File a doc bug.
Done. <http://sourceforge.net/tracker/index.php?func=detail&aid=904498&group_id =5470&atid=105470>. -- Russell
In the threading module, one must of course only start a thread once. I have some questions about handling this gracefully.
First of all, the documentation only says it is an error to start a thread more than once. It does not say which exception is raised. On my system I find it is AssertionError. So...is that going to be true on all systems? Is the test based on "assert", in which case it will go away for optimized code (and then what happens)?
Hey, it's open source! You can look for yourself. :-) Yes, the test is based on assert.
Anyway, if it is always AssertionError, I'd like to get the docs updated to say that.
Disagree. You shouldn't do that. What happens if you ignore the advice needn't be specified.
Also...if possible, it'd be nice to have some way to ask if a thread has ever been started. More generally, it'd be nice to be able to determine what state a thread is in. I'm not sure if there are any states other than ready to run, running and finished. If that's it, perhaps one could add methods isReady and didRun (a getState method would probably be better if there are more states, but then one has to deal with magic constants).
There is isRunning(). Isn't that enough? I realize it doesn't distinguish between "not yet running" and "no longer running", but your application state should be enough to distinguish between the two, right?
I realize it is a common Python paradigm to assume something will work (such as starting the thread) and catch the exception if it doesn't, but: - this is tricky if the exception is not documented - sometimes one simply wants to know, without actually starting the thread
What's your use case? Why can't you add application-specific state to track whatever you're interested in? --Guido van Rossum (home page: http://www.python.org/~guido/)
In article <200402252140.i1PLeoT08847@guido.python.org>, Guido van Rossum <guido@python.org> wrote:
In the threading module, one must of course only start a thread once. I have some questions about handling this gracefully.
First of all, the documentation only says it is an error to start a thread more than once. It does not say which exception is raised. On my system I find it is AssertionError. So...is that going to be true on all systems? Is the test based on "assert", in which case it will go away for optimized code (and then what happens)?
Hey, it's open source! You can look for yourself. :-)
Yes, the test is based on assert.
But if a feature is not documented, it could easily be changed in a future release with no warning. Thus it would be a mistake to assume that this error always raises AssertionError. (Also, since it is based on assert, the error will not even be raised if enables the optimizer?).
... There is isRunning(). Isn't that enough? I realize it doesn't distinguish between "not yet running" and "no longer running", but your application state should be enough to distinguish between the two, right?
I am trying to determine the state of a thread, and in particular determine if it's safe to try to start it. Thus isRunning is explicitly not enough. The result is in my own code I end up writing a status layer around the thread, but I assume many other programmers have to do the same thing. It seems a rather roundabout way to do things when the threading Thread object ought to have a pretty good idea what state it is in. -- Russell
There is isRunning(). Isn't that enough? I realize it doesn't [I meant isAlive()] distinguish between "not yet running" and "no longer running", but your application state should be enough to distinguish between the two, right?
I am trying to determine the state of a thread, and in particular determine if it's safe to try to start it. Thus isRunning is explicitly not enough.
The result is in my own code I end up writing a status layer around the thread, but I assume many other programmers have to do the same thing.
I don't know about that. I almost always create a thread and then immediately start it, so I never have this problem. I assume most other programmers do the same thing.
It seems a rather roundabout way to do things when the threading Thread object ought to have a pretty good idea what state it is in.
I admit, the info is there, but not easily accessible. I copied the Java Thread class, which has the same interface "deficiency". I'm not totally against adding a way to determine a thread's state (with three outcomes: initial, started, stopped) but I'm not quite sure that your use case isn't the result of an awkward way of using threads, in which case I don't want to encourage that. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Aahz -
Guido van Rossum -
Russell E. Owen