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 | amaury.forgeotdarc |
|---|---|
| Recipients | Rhamphoryncus, amaury.forgeotdarc, gregory.p.smith, gvanrossum |
| Date | 2008年01月17日.22:54:38 |
| SpamBayes Score | 0.009581642 |
| Marked as misclassified | No |
| Message-id | <1200610481.14.0.261553012689.issue1856@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Adam, your patch cover one case of the thread releasing the GIL (Py_ALLOW_THREADS), but there are more calls to PyThread_acquire_lock (the checkinterval for example). I have a competing patch: it makes the main thread never release the GIL after some point. Other threads stay blocked and don't clean themselves: the OS will take care of them. Both approaches correct the initial problem, though. A remaining question is where exactly in Py_Finalize() we should ban other threads. I think that this point should be as late as possible, to allow some object/resources to be cleaned properly. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月17日 22:54:41 | amaury.forgeotdarc | set | spambayes_score: 0.00958164 -> 0.009581642 recipients: + amaury.forgeotdarc, gvanrossum, gregory.p.smith, Rhamphoryncus |
| 2008年01月17日 22:54:41 | amaury.forgeotdarc | set | spambayes_score: 0.00958164 -> 0.00958164 messageid: <1200610481.14.0.261553012689.issue1856@psf.upfronthosting.co.za> |
| 2008年01月17日 22:54:39 | amaury.forgeotdarc | link | issue1856 messages |
| 2008年01月17日 22:54:38 | amaury.forgeotdarc | create | |