GNU bug report logs -
#78898
Make read/readevalloop reentrant
Previous Next
Full log
Message #113 received at 78898 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Jul 28, 2025 at 7:57 AM Mattias Engdegård
<mattias.engdegard <at> gmail.com> wrote:
>
> 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.
>
The attached patch set implements what I described as option (3') in
the original email. I've tested the resulting code both with and
without native compilation at -O0, and without native compilation at
the default optimization level, and no new test failures are
introduced (versus commit e3380ed6db7a1c1574c4b39d58f9200a3ffab). In
fact one test failure went away in one of the configurations, though I
have no idea why. It implements
> 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.
Well, this is the first time in my adult life I haven't had an
employer claiming to own every idea or even potential production of
intellectual property regardless of whether it is properly in the
course of employment, so I'm letting myself have some fun with a
program I've liked for most of that adult life. So, there's no simple
concrete problem beyond the statement of the bug itself. I think
Stefan had my number on that.
But, I do have a number of ideas for longer term projects to improve
my favorite editor, like making the lisp machine more concurrency
friendly. For example, eliminating static variables/global state is
part of that, and the reader ecosystem seems like a good place for me
to start. I also want to add lisp objects for capturing grammatical
structure at a more abstract level than tree-sitter (e.g. supporting
an updated Semantic framework), and integrating the construction of
such objects into the lisp reader would be one project.
If you look at the code after applying all three patches, I think the
code is actually simpler, and possibly faster. I can add guard rails
for dealing with the risk of stack overflow. If you really need to
support unbounded expression depth, I can special case allocation of
stack to handle extraordinarily deep expressions. However, I'm not
sure how much benefit there is to being able to process an ELC file
that has a correct header followed by, say a million left parentheses
and then the EOF. If a user wants to handle such outliers, I think
they can be handled without the level of performance provided for more
realistic cases. For example, by allocating a memory segment with
one read stack entry for every byte of the input file to use as the
read stack.
Lynn
[0001-Allocate-reader-stack-on-C-stack.patch (text/x-patch, attachment)]
[0003-Manage-GC-root-for-read-stack.patch (text/x-patch, attachment)]
[0002-Inline-read0_trampoline-at-return-site.patch (text/x-patch, attachment)]
This bug report was last modified 12 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.