Message334451
| Author | ncoghlan |
|---|---|
| Recipients | amaury.forgeotdarc, eric.snow, grahamd, loewis, mhammond, ncoghlan, petr.viktorin, pitrou, python-dev, vstinner |
| Date | 2019-01-28.08:22:21 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1548663741.22.0.968364374064.issue10915@roundup.psfhosted.org> |
| In-reply-to |
| Content | |
|---|---|
A more recent discussion of this on python-dev: https://mail.python.org/pipermail/python-dev/2019-January/156095.html The situation there appears to be a case of "Hand off an OS level thread from the creating interpreter to a different subinterpreter. As far as I can tell, calling GILState_Ensure in such a thread will still acquire the GIL of the creating interpreter (or something equally nonsensical)." It's a single-threaded application using subinterpreters, but all the callbacks from the NumPy code end up hitting the original interpreter that initialised the thread local state in the main thread. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2019-01-28 08:22:22 | ncoghlan | set | recipients: + ncoghlan, loewis, mhammond, amaury.forgeotdarc, pitrou, vstinner, grahamd, petr.viktorin, python-dev, eric.snow |
| 2019-01-28 08:22:21 | ncoghlan | set | messageid: <1548663741.22.0.968364374064.issue10915@roundup.psfhosted.org> |
| 2019-01-28 08:22:21 | ncoghlan | link | issue10915 messages |
| 2019-01-28 08:22:21 | ncoghlan | create | |