Brett Cannon wrote:
> On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
> Brett Cannon wrote:
> > I have been working on a design doc for restricted execution of
> Python
> > [...]
>
> All the rest of the API made sense to me, but I couldn't understand why
>
> PyXXX_MemoryFree
>
> is needed. How could memory usage possibly fall below 0?
>
> It can't in real life, but people could call MemoryFree() too many
> times. Plus you need some way to lower the amount when memory is
> freed. No need to penalize a script that does a bunch of malloc/free
> calls compared to one that just does a bunch of malloc calls.
But if you want to limit the amount of memory a Python interpreter can
use, wouldn't you have to integrate that resource checking into the
standard Alloc/Dealloc functions instead of only enforcing the resource
limit when some new API functions are called?
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.
-Brett
_______________________________________________ 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
