GNU bug report logs - #78898
Make read/readevalloop reentrant

Previous Next

Full log

Message #119 received at 78898 <at> debbugs.gnu.org (full text, mbox):

From: Lynn Winebarger <owinebar <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Pip Cet <pipcet <at> protonmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 78898 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#78898: Make read/readevalloop reentrant
Date: Sat, 2 Aug 2025 07:42:25 -0400

On Wed, Jul 30, 2025 at 9:08 AM Lynn Winebarger <owinebar <at> gmail.com> wrote:
> Without the added block scope, the change becomes very simple.   No
> new test failures (relative to the baseline commit of master) have
> been added.  I can add a slow path for the case where the stack is
> almost overflowing or the input is just ridiculously complicated.  For
> files being loaded, I'd prefer to add a different source type that
> either memory maps the file or slurps it into memory so we can safely
> gauge a worst-case size for the slow path.  A similar approach would
> apply to buffers, since they are already in memory.  For other stream
> types being read, I think erroring out on expressions that would
> overflow the stack is reasonable, given I can build emacs and run all
> the tests without an overflow.  Stefan's preferred benchmark technique
> would be problematic though.  It would almost certainly either
> overflow or take the slow path.

Another way to make this safer is to stop accumulating sequences on
the stack and "reduce" those stack entries early (with Fcons).  That
way, Stefan's benchmark would only add 1 to the maximum stack depth,
rather than making the number of top-level forms the minimum stack
depth.
That will be my next increment.
Lynn

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.