bug 754449 and threads raising exceptions at interpreter teardown
In 2.3, if you have a thread running when the interpreter tears itself down you get an exception from what looks like the thread catching an exception from trying to access something that has been torn down which then raises its own exception from the fact that globals have already disappeared since it tries to access currentThread which is a global (all of this is in my last comment in the bug report). My question is whether this is worth fixing. Since it only occurs if you don't shut down your threads it seems like it is not really a bug but just unexpected behavior from not cleaning up after yourself. But, as I said in my bug report post, I think it is fixable. So is it even worth fixing in some non-pretty way? -Brett
Brett wrote:
My question is whether this is worth fixing. Since it only occurs if you don't shut down your threads it seems like it is not really a bug but just unexpected behavior from not cleaning up after yourself. But, as I said in my bug report post, I think it is fixable. So is it even worth fixing in some non-pretty way?
IMO, any bug is worth fixing. This being free software, contributors are free to chose what they work on. It would be much more useful if you would provide thread cancellation in the process :-) Regards, Martin
Martin v. Löwis wrote:
Brett wrote:
My question is whether this is worth fixing. Since it only occurs if you don't shut down your threads it seems like it is not really a bug but just unexpected behavior from not cleaning up after yourself. But, as I said in my bug report post, I think it is fixable. So is it even worth fixing in some non-pretty way?
IMO, any bug is worth fixing. This being free software, contributors are free to chose what they work on.
So you are classifying this as a bug then. That was part of my question since it only happens if you don't handle your threads properly (or at least I think properly; I would assume it is common practice to close down your threads).
It would be much more useful if you would provide thread cancellation in the process :-)
For some crazy reason having to delve into the world of thread libraries for those cases where there is not an equivalent pthread_cancel does not sound fun. =) -Brett
At 04:24 PM 2/9/04 -0800, Brett wrote:
For some crazy reason having to delve into the world of thread libraries for those cases where there is not an equivalent pthread_cancel does not sound fun. =)
Presumably, you could make those either raise NotImplementedError, or not export the cancellation function to the thread module. Since people writing backward-compatible code will want to check for the existence of such a function anyway, it should not be a significant drawback to provide it only on platforms that are easily supported. And, once you've written an example, others who have more familiarity with those other platforms might be more motivated to supply patches adding the feature to those as well. :)
Brett wrote:
So you are classifying this as a bug then. That was part of my question since it only happens if you don't handle your threads properly (or at least I think properly; I would assume it is common practice to close down your threads).
Certainly: in a properly working program, one would terminate all threads first before trying to exit the program. Failure to do so should cause an exception (or otherwise have an "obvious" meaning). However, that exception should not be a "double-fault"; instead, it should give a clear indication what the problem is.
For some crazy reason having to delve into the world of thread libraries for those cases where there is not an equivalent pthread_cancel does not sound fun. =)
You could safely assume that there is an equivalent to pthread_cancel; not having thread cancellation on non-pthreads-non-win32 systems seems acceptable to me (especially since we don't have thread cancellation on any system at the moment). Unfortunately, pthread_cancel is insufficient for Python, as you also want stack-unwinding on the cancelled thread, so that it can decref all objects it holds. If you can make this work, we could specify that exiting the interpreter when some threads are still sleeping inside Python code causes those threads to be cancelled. Regards, Martin
On Tue, 2004-02-10 at 13:54, "Martin v. Löwis" wrote:
Brett wrote:
So you are classifying this as a bug then. That was part of my question since it only happens if you don't handle your threads properly (or at least I think properly; I would assume it is common practice to close down your threads).
Certainly: in a properly working program, one would terminate all threads first before trying to exit the program. Failure to do so should cause an exception (or otherwise have an "obvious" meaning). However, that exception should not be a "double-fault"; instead, it should give a clear indication what the problem is.
What about daemon threads? They are running by intention when the program exits, otherwise they wouldn't be daemon threads. Jeremy
Jeremy Hylton wrote:
What about daemon threads? They are running by intention when the program exits, otherwise they wouldn't be daemon threads.
Right. Shutting down a process using daemon threads should not cause an exception. So this is clearly a bug, or it would be one if it was reproducable in an example involving daemon threads. Regards, Martin
[Martin v. Löwis]
Right. Shutting down a process using daemon threads should not cause an exception. So this is clearly a bug, or it would be one if it was reproducable in an example involving daemon threads.
The Zope3 test suite left a bunch of daemon threads around, and had lots of shutdown problems in the original 2.3. I even provoked a shutdown segfault once by putting print stmts in the threads, trying to see what was going wrong in them. This is one reason I changed 2.3.3 to stop calling gc a second time in Py_Finalize. Other reasons are explained in a comment block there, and an earlier comment explains how you can still provoke shutdown exceptions easily via a different route, up to & including "Fatal Python error". A fundamental problem is that if just about anything gets reclaimed during finalization, __del__ methods or weakref callbacks can get invoked, and as soon as we're back running Python code, it's open season on the GIL, so any number of threads can try to do anything. Since the interpreter is in the middle of being torn down, bad things can happen. Armin Rigo posted a patch (on SF) moving toward using gc to tear things down in a kinder order. I never had time to look into that, but it sounded like a promising approach.
So you are classifying this as a bug then. That was part of my question since it only happens if you don't handle your threads properly (or at least I think properly; I would assume it is common practice to close down your threads).
Really? I would assume it's common practice to let the garbage collector shut down your threads. After all, people don't handle errors either. Most code doesn't even check for them. Bill
On Tue, 2004-02-10 at 19:44, Bill Janssen wrote:
So you are classifying this as a bug then. That was part of my question since it only happens if you don't handle your threads properly (or at least I think properly; I would assume it is common practice to close down your threads).
Really? I would assume it's common practice to let the garbage collector shut down your threads. After all, people don't handle errors either. Most code doesn't even check for them.
I don't trust the garbage collector to have any sane shutdown semantics, especially regarding threads. In my own code, I always make the best effort to shut threads (daemon or otherwise) down explicitly. -Barry
I don't trust the garbage collector to have any sane shutdown semantics, especially regarding threads. In my own code, I always make the best effort to shut threads (daemon or otherwise) down explicitly.
Shutting down daemon threads is an oxymoron. --Guido van Rossum (home page: http://www.python.org/~guido/)
I don't trust the garbage collector to have any sane shutdown semantics, especially regarding threads. In my own code, I always make the best effort to shut threads (daemon or otherwise) down explicitly.
Sure, you and me both. But I doubt it's common practice. The garbage collector should make a real effort to do something sensible. Bill
participants (8)
-
"Martin v. Löwis" -
Barry Warsaw -
Bill Janssen -
Brett -
Guido van Rossum -
Jeremy Hylton -
Phillip J. Eby -
Tim Peters