+emacs-devel

---------- Forwarded message ---------
From: yyoncho <yyoncho@gmail.com>
Date: Sat, Sep 29, 2018 at 12:39 AM
Subject: Re: Running process filters in another thread
To: <eliz@gnu.org>


Hi Eli,

Thanks for the quick response!

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.

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?

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.

Thanks,
Ivan

On Sat, Sep 29, 2018 at 12:14 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: yyoncho <yyoncho@gmail.com>
> > Date: Fri, 28 Sep 2018 21:21:23 +0300
> >
> > I want to raise this topic regarding the rise of Language servers and
> the performance
> > problems that are related to parsing process output on UI thread.
> >
> > I am not familiar with emacs internals and I am not sure whether this is
> doable
> > but I wonder whether providing the option to do the parsing(and probably
> more?)
> > in a separate thread and then call the *filter* function on emacs side
> in UI
> > thread with elisp data structures like lists, hashmaps etc. instead of
> raw
> > string is feasible which would be similar to what is happening in
> Javascript world.
>
> Emacs threads are cooperative, and only one thread can run at any
> given time.  So it i's unclear to me how running process filters in a
> separate thread will help improve the performance in this case,
> because Emacs will still be locked up when that other thread runs the
> filter.
>
> Or am I missing something?
>