GNU bug report logs -
#78898
Make read/readevalloop reentrant
Previous Next
Full log
Message #65 received at 78898 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm attaching a unified patch with a more cogent commit message. The
previous patch series had a number of misfeatures in the initial patch
backed out by subsequent patches. This patch should remove the need
to review code that is not ultimately used.
Lynn
On Thu, Jul 3, 2025 at 10:47 PM Lynn Winebarger <owinebar <at> gmail.com> wrote:
>
> The attached patch (in addition to the preceding 2) eliminates most of
> the errors from "make check". I've attached the ones from edebug. I
> see "edebug-tests-break-in-lambda-out-of-defining-context" fail in my
> build of the master checkout, so that leaves two unexplained failures,
> edebug-tests-step-into-function and
> edebug-tests-trace-function-call-and-return. I currently have no idea
> what is going on. The other 67 (or thereabouts) errors were fixed by
> 1. making the control flow more faithful to the original for
> eval-region [ about 35 tests]. I split LREAD_FRAME_MULTIPLE into
> LREAD_FRAME_INTEGRAL (where all lisp state changes are integrated) and
> LREAD_FRAME_DYNAMIC_WIND (where eval-region provides some protection
> of the current buffer state). The previous version of the code relied
> on !NILP(start) to prompt this protective wind-down/wind-up behavior
> between read and eval.
> 2. Ensure that if readfun is called and generates an eof due to the
> point moving to the end of the region, any expression returned gets
> evaluated before the eof is honored in readevalloop.
> 3. ensuring that calling "load-read-function" uses the buffer as a
> stream argument if that is the input for the frame. Edebug relies on
> this undocumented behavior in advising load-read-function to
> instrument code being debugged [20+ tests].
> 4. Getting rid of the new signal handlers used to bypass frames - may
> have been responsible for one or two test failures. They were mainly
> an experiment to understand how the dynamic stack works and if a more
> explicit dynamic-wind type behavior would work if code rand while
> processing a maybe_quit. I'm not sure if this changes an observed
> test results, but it doesn't really do anything useful beyond testing
> how the idea might actually work. So, calls to read are still
> susceptible to eof signals generated but not handled by elisp code run
> while reading the stream.
>
> I can't perceive any difference in startup time with the debug build
> compiled without support for native compilation.
>
> Overall results of 'make check'
> SUMMARY OF TEST RESULTS
> -----------------------
> Files examined: 533
> Ran 8119 tests, 7959 results as expected, 27 unexpected, 133 skipped
> 4 files contained unexpected results:
> lisp/vc/vc-tests/vc-tests.log
> lisp/progmodes/python-tests.log
> lisp/progmodes/c-ts-mode-tests.log
> lisp/emacs-lisp/edebug-tests.log
>
> For the non-edebug tests, I get the same failures for my reference
> checkout on my test system.
> I'd be happy to take any hints on those two remaining edebug
> regressions. I have no idea what the difference of interest is
> between those two and all the other similar looking tests is, in terms
> of reliance on the behavior of
> eval-region/eval-buffer/load-read-function.
[0001-Make-read-readevalloop-jointly-reentrant.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.