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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4