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

Previous Next

Package: emacs;

Reported by: Lynn Winebarger <owinebar <at> gmail.com>

Date: Wed, 25 Jun 2025 22:01:05 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
To: Lynn Winebarger <owinebar <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: bug#78898: Make read/readevalloop reentrant
Date: Mon, 28 Jul 2025 13:57:15 +0200
24 juli 2025 kl. 00.53 skrev Lynn Winebarger <owinebar <at> gmail.com>:

> (1) Just reserve a conservatively large amount of stack space at the start and abort if it's exceeded.  A lisp variable could be used to let the user change the size of the reserved space between activations of read0, like the maximum lisp recursion depth.
> 
> (2). Allocate an array in the C stack on entry to read0 for the reader stack.  During the parse, if all array entries are used, just use C recursion to call read0.
> 
> (3) Reverse the order of call and return in the recursion of option (2).  Meaning, enter read0 with a trampoline that allocates the reader stack with alloca.  On entry to the read_obj label,  check that there is enough stack space for the maximum number of entries that can be pushed before control returns to read_obj.  If there is not enough space, return to the trampoline.  The trampoline calls read0 in a do...while loop as long as the stack is nonempty, then returns.  Since the read stack is implemented in a simple trampoline function, each alloca just extends the initial reader stack array, so growing that array never requires copying.

Thank you, but it's not quite what we had in mind so I think we'll pass on that for now.

More generally, it's not entirely clear what concrete problem you are actually trying to solve.





This bug report was last modified 13 days ago.

Previous Next


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