[Python-Dev] doc for new restricted execution design for Python
Bob Ippolito
bob at redivi.com
Sat Jun 24 12:22:32 CEST 2006
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.
-bob
More information about the Python-Dev
mailing list