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 | Rhamphoryncus |
|---|---|
| Recipients | Rhamphoryncus, amaury.forgeotdarc, gregory.p.smith, gvanrossum, kbk, larsimmisch |
| Date | 2008年05月07日.18:11:43 |
| SpamBayes Score | 0.009410914 |
| Marked as misclassified | No |
| Message-id | <1210183915.75.0.0624230391664.issue1856@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Cleaned up version of Amaury's patch. I stop releasing the GIL after sys.exitfunc is called, which protects threads from the ensuing teardown. I also grab the import lock (and never release it). This should prevent the nasty issue with daemon threads doing imports mentioned in issue 1720705, so that part of the documentation change can be removed. I didn't do any significant testing though. Importing raises a potential issue with this approach. The standard meme of "release GIL; grab lock; acquire GIL" becomes invalid. A child may grab the lock, then block on the GIL, while the main thread (which never releases the GIL) will block on acquiring the lock. I worked around it with the import lock due to it's recursive behaviour, but if it exists anywhere else in CPython it may cause a problem if used during shutdown. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年05月07日 18:11:56 | Rhamphoryncus | set | spambayes_score: 0.00941091 -> 0.009410914 recipients: + Rhamphoryncus, gvanrossum, gregory.p.smith, kbk, amaury.forgeotdarc, larsimmisch |
| 2008年05月07日 18:11:55 | Rhamphoryncus | set | spambayes_score: 0.00941091 -> 0.00941091 messageid: <1210183915.75.0.0624230391664.issue1856@psf.upfronthosting.co.za> |
| 2008年05月07日 18:11:54 | Rhamphoryncus | link | issue1856 messages |
| 2008年05月07日 18:11:52 | Rhamphoryncus | create | |