Re: Running process filters in another thread

[Eli Zaretskii]

> From: yyoncho <address@hidden>
> Date: Sat, 29 Sep 2018 10:35:19 +0300
> Cc: address@hidden
> 
> 1. You could have multiple running LSP servers and each of them could post 
> big(1m+)
> updates at any time.

That's okay, since Emacs processes input from subprocesses only when
it's idle.  So as long as the user types commands, neither the user
nor the Lisp code that those commands run will be interrupted.

> My point is that Emacs should be able to process a lot of json 
> requests/responses
> and still being responsive and if this requires parsing some text format
> messages(e. g. Json/XML/emacs built-in) on UI thread this is not going to
> happen.

I'm not sure I understand why this couldn't happen.

> > It shouldn't be too hard to use a separate (OS-level) Emacs *process*
> > if you want to do the parsing without blocking the normal UI thread.
> > But it comes with other performance tradeoffs.
> 
> Please correct me if I am wrong but I believe that I will still have to parse
> the input on UI thread but from a different format(e. g. using built-in
> print1/read) which in the end will have the same result.

No, you could have the subprocess send a parsed JSON object, I think.

But all of this is pure theory.  I suggest to create a benchmark for
parsing a large input of the kind that's expected from LSPs, and then
time it with the native JSON support in Emacs 27.  Then we will have a
better idea of what issues are involved.