GNU bug report logs - #38807
[Feature request]: Support lisp workers like web workers.

Previous Next

Full log

View this message in rfc822 format

From: HaiJun Zhang <netjune <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Ivan Yonchovski <yyoncho <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 38807 <at> debbugs.gnu.org
Subject: bug#38807: [Feature request]: Support lisp workers like web workers.
Date: Sun, 29 Mar 2020 10:41:51 +0800

[Message part 1 (text/plain, inline)]

在 2020年3月27日 +0800 AM2:15，Ivan Yonchovski <yyoncho <at> gmail.com>，写道：
>
> Eli Zaretskii writes:
>
> > Since the user waits for this job to finish anyway, why does it help
> > to run some of this processing in a separate thread?
>
> The user might not want to wait for the completion but he/she might want
> to continue to type while the parsing is taking place. The effect is
> that the typing feels slugish. IME with latest native json parsing this
> is no longer the case for lsp-mode.
>
>
> With my limited understanding of emacs internals I see 2 potential
> solutions to allow writing of "lisp workers".
>
> 1. Start second(or multiple) elisp interpreter in the emacs process
> which has thread local copy of all of the global data(buffers, data
> allocation, etc). It may or may not have a gui attached to it. In
> addition to that, introduce primitives for moving elisp datastructure
> from the background thread to the main UI thread and vice versa
> eventually by coping the original structure to avoid bugs.
>

I’d like not expose any global data to them. Even the data allocation can be standalone. Then they pass lisp object by coping as you said.

> 2. Make the functions that create elisp datastructures threadsafe(or
> some sane subset) and expose them to the dynamic modules.
>
> Thanks,
> Ivan

[Message part 2 (text/html, inline)]

Previous Next

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