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日.23:23:38 |
| SpamBayes Score | 0.0051264237 |
| Marked as misclassified | No |
| Message-id | <1200612219.88.0.401834234216.issue1856@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
> That doesn't matter. PyGILState_Ensure needs to remain valid > *forever*. Only once the process is completely gone can we be sure > it won't be called. We could apply the same idea: when exiting, PyGILState_Ensure() blocks forever, except for the main thread of course. Note that all this state must be restartable: after Py_Finalize(), it should be possible to call Py_Initialize() again. This seems to raise the score of the "exit_thread" approach. I don't know if multiple interpreters are well supported, though. Is there somewhere a list of use cases, or a test script that can exercise this? |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月17日 23:23:40 | amaury.forgeotdarc | set | spambayes_score: 0.00512642 -> 0.0051264237 recipients: + amaury.forgeotdarc, gvanrossum, gregory.p.smith, Rhamphoryncus |
| 2008年01月17日 23:23:39 | amaury.forgeotdarc | set | spambayes_score: 0.00512642 -> 0.00512642 messageid: <1200612219.88.0.401834234216.issue1856@psf.upfronthosting.co.za> |
| 2008年01月17日 23:23:38 | amaury.forgeotdarc | link | issue1856 messages |
| 2008年01月17日 23:23:38 | amaury.forgeotdarc | create | |