[Python-Dev] doc for new restricted execution design for Python

[Brett Cannon]

On 6/22/06, Gerhard Häring <gh at ghaering.de> wrote:
>
> Brett Cannon wrote:
> > On 6/22/06, *Gerhard Häring* <gh at ghaering.de <mailto:gh at ghaering.de>>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060622/69bbf783/attachment.htm