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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
