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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lynn Winebarger <owinebar <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Mattias Engdegård <mattiase <at> acm.org>
Cc: 78898 <at> debbugs.gnu.org
Subject: Re: bug#78898: Make read/readevalloop reentrant
Date: Sat, 28 Jun 2025 13:08:44 +0300

> From: Lynn Winebarger <owinebar <at> gmail.com>
> Date: Wed, 25 Jun 2025 17:59:53 -0400
> 
> In the recursive sense, not the "safe for concurrency" sense.
> 
> I want to use readevalloop to process command-line arguments, and my
> initial attempts failed to handle '"(load "loadup.el") (princ
> "Done")'.  So I took a stab at making all the entry points synchronize
> with an explicit stack of continuation frames shared between read0 and
> readevalloop.
> 
> The attached diff is against master from a couple of days ago.  For
> me, a configure/build (from scratch) completes *almost* everything
> (including the standard AOT native-compiled bits) - it chokes on
> lisp/leim/ja-dic.el due to a failure in a compiled function in
> bytecomp.elc.  There are clearly still some issues where the new code
> is not dealing with unibyte/multibyte correctly.  For example, running
> emacs -Q shows the initial scratch buffer contents as:
> 
> ;; This buffer is for text that is not saved, and for Lisp evaluation.
> ;; To create a file, visit it with ‘C-x C-f’ and enter text in its buffer.
> 
> This is definitely not ready for committing, but I'm hoping someone
> else finds this of interest and maybe can spot where I'm going wrong
> with the unibyte/multibyte handling.  Or what is going on with
> ja-dic.el.  The error I'm seeing there is in the execution of some
> byte-code, where some bit-wise operator gets a non-numeric argument.
> My only idea at present is to diff the byte-compiled libraries and see
> what's going on there - theoretically, there shouldn't be any change
> in the results of the byte-compiler.

Stefan and Mattias, any comments to this proposal?

Do we really want readevalloop be recursive this way?  What does this
gain us?

Previous Next

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