PyNumber_Int screwing Object.

[Bengt Richter]

On Mon, 6 Oct 2003 20:07:54 -0400, "Tim Peters" <tim.one at comcast.net> wrote:

>[Bengt Richter]
>> A thought -- is there any guarantee that there will be enough memory
>> to process an oom exception?
>
>Read your OS owner's manual and see what guarantees they make when you're
>out of memory.  Python can't guarantee more than that.  The internal
>PyErr_NoMemory() tries to use a preallocated instance of the MemoryError
>class so that it won't run out of memory again trying to raise the
>exception, but there's certainly no guarantee you have enough memory to get
>into a Python function after that.
>
>> Could there be an app-accessible s/w lever somewhere that one could
>> kick over for reserve memory (assuming getting to the exception
>> handler is guaranteed), like my old VW bug used to have?
>>
>> It would sputter and lunge when I "ran out" of gas on the freeway to
>> work, and I'd just kick the little black lever on the firewall over
>> 90 degrees, and sputter, lunge, continue (don't want to forget the
>> state of that lever though ;-)
>
>On systems where the C library supports flip_malloc_reserve_lever(), no
>problem.  On other systems Python could hold one byte in reserve, just as
one byte? how about a configurable amount defaulting to a meg?
>soon as you contribute code to make that happen <wink>.
I had the unverified impression that python got raw memory for small stuff wholesale,
and suballocated from its own pools, so the issue would seem to come up when either
replenishing the pools fails, or an app-level allocation of something large fails.
Either way, if you replenished pools from a reserved wholesale chunk at that point, perhaps
things could unwind better, assuming that the unwinding process doesn't try to allocate more
big stuff? It might even recover, if the reserve could be re-established after
the exception was handled. Of course, people couldn't use exception catchalls willy-nilly.

Regards,
Bengt Richter