GNU bug report logs - #61350
Eglot over Tramp freezes with large project

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Thomas Koch <thomas <at> koch.ro>, Michael Albinus <michael.albinus <at> gmx.de>,
 João Távora <joaotavora <at> gmail.com>,
 61350 <at> debbugs.gnu.org
Subject: Re: bug#61350: Eglot over Tramp freezes with large project
Date: Thu, 16 Mar 2023 09:25:51 -0400

>> SLY, jsonrpc.el, and other code is synchronous as well (the completion
>> API is synch, as you well know).  `accept-p-o` + a filter that invokes
>> a closure that throws out of the loop is a great way to do this.
>> See jsonrpc-request, for example.  No JUST-THIS-ONE, and has
>> been working fine in many forms since Emacs 24.3 AFAIK.
>
> Assuming I understand the context here correctly, this sort of thing is part
>  of why Chris Wellons' emacs-aio package uses 'run-at-time' for handling
> resolved promises[1]:
>> If the result is ready call the callback in the next event loop turn using
>> run-at-time. This is important because it keeps all the asynchronous
>> components isolated from one another. They won’t see each others’ frames
>> on the call stack, nor frames from aio. This is so important that the
>> Promises/A+ specification is explicit about it.

My futur.el code does the same, indeed (tho it uses `funcall-later`
which I implemented in C to expose to ELisp the `pending_funcalls` we
already had in C).


        Stefan

Previous Next

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