Message126363
| Author |
pitrou |
| Recipients |
amaury.forgeotdarc, grahamd, loewis, ncoghlan, pitrou |
| Date |
2011年01月16日.10:56:42 |
| SpamBayes Score |
3.023446e-10 |
| Marked as misclassified |
No |
| Message-id |
<1295175399.3784.23.camel@localhost.localdomain> |
| In-reply-to |
<1295139119.17.0.360470380045.issue10915@psf.upfronthosting.co.za> |
| Content |
> The bulk of use cases is going to be simple callbacks via the same
> thread that called out of Python in the first place. [...]
> This is what SWIG effectively does in its generated wrappers for
> callbacks.
Thanks for clarifying. I agree the TLS scheme would help in these cases.
There is still the question of what/who updates the TLS mapping; you are
proposing a new API call; an alternative is to do the mapping in e.g.
PyEval_SaveThread().
> The reality is that if you force a change on every single extension
> module doing callbacks into the interpreter without having the GIL
> first, you will never see people update their code as they will likely
> not care about this special use case. And so the whole point of adding
> the additional APIs will be wasted effort and have achieved nothing.
I'm not sure I care. If people don't want to use the new APIs on the
basis that they are slightly more complex, then it's their problem. The
Python C API tries not to be too cumbersome, but it cannot pretend to be
as transparent as a high-level API in a dynamic language. |
|