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 steve.dower
Recipients BTaskaya, Mark.Shannon, kj, orsenthil, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2021-09-06.17:08:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1630948111.59.0.549508068766.issue44348@roundup.psfhosted.org>
In-reply-to
Content
It should also be possible to reduce the stack size of each frame. We've done that before, because there were multiple temporary buffers allocated on the stack that were trivially moved into functions. I bet we can also reduce the number of indirections, as last time I had to investigate a native stack we seem to have bloated up to 6-7 C frames for each Python frame.

Failing that, I'd rather have an option to build with higher stack size just for tests (or users who care that much - my experience is that people tend to care more about many Python processes rather than high recursion). That only affects python[w][_uwp].exe.

We could also add a threading API to allow creating new threads with larger stack size. That would allow us to write tests that can do it, and also enable users who may run into it. I'd prefer Windows just be able to expand the stack better at runtime, but the reserved address space apparently wins the back-compat argument.
History
Date User Action Args
2021-09-06 17:08:31steve.dowersetrecipients: + steve.dower, paul.moore, orsenthil, vstinner, tim.golden, Mark.Shannon, zach.ware, pablogsal, BTaskaya, kj
2021-09-06 17:08:31steve.dowersetmessageid: <1630948111.59.0.549508068766.issue44348@roundup.psfhosted.org>
2021-09-06 17:08:31steve.dowerlinkissue44348 messages
2021-09-06 17:08:31steve.dowercreate