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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: 78898 <at> debbugs.gnu.org
Subject: bug#78898: Make read/readevalloop reentrant
Date: Sun, 29 Jun 2025 00:51:30 -0400

> It's true that read and readevalloop are distinct, but, ignoring the
> readfun parameter of readevalloop, any static variables read0 is dependent
> on, readevalloop is also dependent on.  It's also true that not every entry
> to read0 is an entry to readevalloop, but practically every entry to
> readevalloop will enter read0.  And they both depend on the state accessed
> by readchar and unreadchar.

I'm afraid I still have no idea why the above is relevant.

> So, readevalloop can never really be reentrant as long as
> read0/readchar/unreadchar are not.

That's obviously not true: every `load` calls `readevalloop` and from
there it can all other `load`s.  So when file A `require`s file B which
`require`s file C, you're using `readevalloop` in a reentrant way.

> My initial (current) approach has been to identify all the private
> state in lread.c accessed

You tell me how you go about solving your problem, but I don't know
what is the problem you're trying to solve.

> Initially, I had tried implementing a simple read-eval loop for processing
> sequences of expressions in a string, similar to "load" for files or
> "eval-buffer".

You can easily write this in ELisp, so I don't see how that relates to
any part of the C code.

> I considered that even if I determined the proximate cause of the issue, it
> would be difficult to tell whether any particular solution would be TRT or
> just a band-aid. So, I suppose the most immediate advantage for me is
> improving my ability to debug recursive invocations of read0/readevalloop
> by looking at the explicit stack of frames.

How/when&why do you expect/want `read` to be called recursively?

> So, for example, I've implemented an input stream "reader-input-stream"
> that can be used arbitrarily by code being evaluated for characters from
> the "current" input stream, which is pretty much impossible in the current
> implementation.  It's main use is for "readfun" in readevalloop.
> Implementing "eval-stream", which evaluates all input streams as programs
> uniformly, becomes trivial.

I don't know what "evaluates all input streams as programs
uniformly" means, nor do I know what "eval-stream" refers to (is that
the name of a standard function in some language?  What does it do?).


        Stefan

Previous Next

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