This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author meador.inge
Recipients amaury.forgeotdarc, belopolsky, meador.inge, vstinner
Date 2011-12-01.04:24:07
SpamBayes Score 1.723508e-07
Marked as misclassified No
Message-id <CAK1QoordVB_7SRiK0kFZ8QSCLsqruF7F+FaKEGmhQN+UTERPUw@mail.gmail.com>
In-reply-to <1322655604.23.0.598398075147.issue13097@psf.upfronthosting.co.za>
Content
On Wed, Nov 30, 2011 at 6:20 AM, Amaury Forgeot d'Arc
<report@bugs.python.org> wrote:

> Right, alloca() could be replaced by some malloc(), but is it really useful?  After all, when a C function calls back to Python, all arguments needs to be > pushed to the stack anyway.

The case is somewhat pathological.  However, there are *four* 'alloca'
calls in '_ctypes_callproc', three of which are proportional to
'argcount'.  And as you point out there is an additional stack
allocation inside of 'libffi' when the callback is actually called
(also using 'alloca').

I see two reasons switching to 'malloc' might be beneficial: (1) by
shifting some of the allocation to dynamic allocation we may reduce
the chance that we blow the stack at all.  Keep in mind that this gets
more likely if the C ffi function is called from a deep in a call tree
and *not* necessarily with just a huge number of parameters.  (2) if
resources are exhausted, then we can exit more gracefully.  Out of
dynamic memory errors can actually be handled as opposed to an
'alloca' call that ends up allocating more than is left.

That being said, if this does get changed it is low priority.
History
Date User Action Args
2011-12-01 04:24:10meador.ingesetrecipients: + meador.inge, amaury.forgeotdarc, belopolsky, vstinner
2011-12-01 04:24:09meador.ingelinkissue13097 messages
2011-12-01 04:24:08meador.ingecreate