bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61350: Eglot over Tramp freezes with large project


From: Michael Albinus
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Tue, 14 Mar 2023 16:42:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

João Távora <joaotavora@gmail.com> writes:

Hi João,

>> I will investigate. IMHO, this is the final indication that we shouldn't
>> allow a nil JUST-THIS-ONE in accept-process-output.
>
> I don't see this failure as an indication of that, at all!!
>
> First, you didn't do that -- put nil in JUST-THIS-ONE --  did you?
> At most this means that you are doing more or less the same
> as setting JUST-THIS-ONE to nil, but in a much more convoluted
> way, so that you may as well start setting JUST-THIS-ONE to nil...

It is an indication, that, if some processes accept output at the same
time, and this output runs through process filters, anything can happen.

No, I didn't set JUST-THIS-ONE to nil. I just allow related processes,
belonging to the same Tramp connection, to do so. This is a case we have
under our control. When JUSt_THIS-ONE is set to nil, the same could
happen to any arbitrary process running randomly in concurrency to a
Tramp process, and this we wouldn't have under our control.

> ...and bite the bullet, continuing this analysis.  We're making
> progress...

Sure, I'll do. Coincidently, the author of filenotify.el and
filenotify-tests.el is well known to us, I'll contact him :-)

> For me, this means that those auto-revert and symlinks-remote tests,
> whatever they are, must be investigated. It's good that you have these
> tests! Do they fail in all Emacsen or just some? Always/sometimes?
> Can I reproduce this here?

This happens with Emacs master (which runs on EMBA). And I could
reproduce it locally, with slightly modified error messages, by

--8<---------------cut here---------------start------------->8---
# make -C test filenotify-tests
--8<---------------cut here---------------end--------------->8---

> After we get a consistent failure, we should ask ourselves what exactly
> is the reentrancy in question here. Perhaps you already have a conjecture
> of the chain of events that leads to it.

Yes, I have. Contacting the author ...

> João

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]