This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients kristjan.jonsson, neologix, pitrou, sbt
Date 2013-05-14.13:56:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1368539766.57.0.621250782483.issue17969@psf.upfronthosting.co.za>
In-reply-to
Content
Richard, I'll review implement your change.  It is a bit tricky to test this, since I can only tell after a few days if the particular (rare) problem has been fixed.  The crash is a rare one but consistently happens with some probability we use multiprocessing to perform certain batch processing.

About regressions:  The term means that problems, previously fixed, become broken again.  All fixes should reasonably have appropriate tests in the regression test suite.

I don't know what particular "regressions" you have been battling since 2.7.4.  I hope they are all testable by now.
I only know that there is a exit problem with multiprocessing that statistically happens and is problemematic.  It caused use to stop using multiprocessing and parallel jobs until I could diagnose the problem.  I have suggested several fixes to this particular problem.

I have two favorites, which would also help in the general case:
1) calling sys.exc_clear() at the beginning of the python finalize part, to throw out any lingering traceback and frame objects.  This will cause side effects such as gil-twiddling to happen early, and without consequence.  sys.exc_clear() is a safe api and used throughout the code, an extra call just prior to exit should be a very safe operation.
2) Turn off multi-threading at the start of python exit, by setting interpreter_lock to NULL.  Again, this is a no-brainer, since the NULL value is already well defined and works well.  It will cause all subsequent GIL releases to be no-ops.

I personally favor the second one.  It makes no sense to allow other threads to run after finalization has started and forcing them to stay dead is only prudent.

2.7 is not frozen, and it is in bug fix mode.  If a solid bug fix to an actual problem is proposed, we should embrace it, and deal with any eventual fallout appropriate as the price of doing business.  2.7 is a product that is alive and well, used by millions of people and thousands of businesses and will remain so for quite some time.  I know that most of the core devs have moved on to greener pastures, but I for one would like to stay loyal to this workhorse of a product and continue to make necessary improvements to it.
History
Date User Action Args
2013-05-14 13:56:06kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, neologix, sbt
2013-05-14 13:56:06kristjan.jonssonsetmessageid: <1368539766.57.0.621250782483.issue17969@psf.upfronthosting.co.za>
2013-05-14 13:56:06kristjan.jonssonlinkissue17969 messages
2013-05-14 13:56:05kristjan.jonssoncreate