[Python-Dev] doc for new restricted execution design for Python (original) (raw)
Bob Ippolito bob at redivi.com
Sun Jun 25 22:57:55 CEST 2006
- Previous message: [Python-Dev] doc for new restricted execution design for Python
- Next message: [Python-Dev] doc for new restricted execution design for Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jun 25, 2006, at 1:08 PM, Brett Cannon wrote:
On 6/24/06, Bob Ippolito <bob at redivi.com> wrote:
On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote: > Brett Cannon wrote: >> Yep. That API will be used directly in the changes to pymalloc and >> PyMem*() macros (or at least the basic idea). It is not only for >> extension modules but for the core as well. >> >> Existing extension modules and existing C code in the Python >> interpreter >> have no idea of any PyXXX calls, so I don't understand how >> new API >> functions help here. >> >> >> The calls get added to pymalloc and PyMem*() under the hood, so that >> existing extension modules use the memory check automatically >> without a >> change. The calls are just there in case some one has some random >> need >> to do their own malloc but still want to participate in the cap. >> Plus >> it helped me think everything through by giving everything I would >> need >> to change internally an API. > > This confused me a bit, too. It might help if you annotated each of > the new > API's with who the expected callers were: > > - trusted interpreter > - untrusted interpreter > - embedding application > - extension module Threading is definitely going to be an issue with multiple interpreters (restricted or otherwise)... for example, the PyGILState API probably wouldn't work anymore.
PyGILState won't work because there are multiple interpreters period, or because of the introduced distinction of untrusted and trusted interpreters? In other words, is this some new possible breakage, or is this an issue with threads that has always existed with multiple interpreters?
It's an issue that's always existed with multiple interpreters, but
multiple interpreters aren't really commonly used or tested at the
moment so it's not very surprising.
It would be kinda nice to have an interpreter-per-thread with no GIL
like some of the other languages have, but the C API depends on too
much global state for that...
-bob
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060625/c250a12c/attachment.html
- Previous message: [Python-Dev] doc for new restricted execution design for Python
- Next message: [Python-Dev] doc for new restricted execution design for Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]