Re: Fwd: Running process filters in another thread

[Eli Zaretskii <eliz@gnu.org>]

> From: yyoncho <yyoncho@gmail.com>
> Date: Sat, 29 Sep 2018 09:54:30 +0300
> 
> Excuse me if I am talking nonsense - my understanding is that there are Emacs threads(the threads that are
> available using elisp code) which run cooperatively and there are OS level threads which for example read the
> output of a process and then pass it to the filter function as a string and they might run in parallel and I was
> talking about running the pre-filter function into such thread. 

Emacs reads output from subprocesses in its "normal" Lisp thread(s).
No special threads are involved.

> If this is not the case, I guess it won't be easy to spawn new os thread and run eventually *pure* function to
> process the output?

This should be possible, but I think we wouldn't like doing that, as
running async threads that need to feed the main thread is tricky, and
doesn't really go well with the architecture of Emacs.

> Alternatively, I was thinking about creating some faster emacs specific binary serialization/deserialization of
> data structures so elisp programmers could move the parsing into separate emacs instance(ala
> https://github.com/jwiegley/emacs-async) and then consume the output. 

Something like that, yes.  But I think we should first understand well
what part(s) of the LSP processing takes most CPU cycles, and then
discuss how best to integrate that into Emacs.  It could be, for
example, that implementing some portions of that in C will provide new
primitives that would allow to slash the processing time without
complicating the architecture.