From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: yyoncho Newsgroups: gmane.emacs.devel Subject: Fwd: Running process filters in another thread Date: Sat, 29 Sep 2018 09:54:30 +0300 Message-ID: References: <83bm8h729x.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e600e00576fd0b5b" X-Trace: blaine.gmane.org 1538204007 20472 195.159.176.226 (29 Sep 2018 06:53:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 06:53:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 29 08:53:23 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g697y-0005A0-IJ for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 08:53:22 +0200 Original-Received: from localhost ([::1]:49633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g699z-0001j9-RD for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 02:55:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g699I-0001j2-1F for emacs-devel@gnu.org; Sat, 29 Sep 2018 02:54:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g699H-000551-16 for emacs-devel@gnu.org; Sat, 29 Sep 2018 02:54:43 -0400 Original-Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]:40610) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g699G-00054l-Rv for emacs-devel@gnu.org; Sat, 29 Sep 2018 02:54:42 -0400 Original-Received: by mail-ot1-x32d.google.com with SMTP id e23-v6so3961119otl.7 for ; Fri, 28 Sep 2018 23:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RdC8zdeMkDnxJigRR5i6H1m668be4V9/Va0O0I6r5Yk=; b=Ud4aRbNtrR74z+CwRC6Me0N5j7qw1TM0V8RMRrIN4ehQo3j4ZzHHiHle7RcpMWL8Oo dQL8NPGS9RbJhkVpg+JUCuC3OSc9qu5MnUcEMWe//lzi0ziE2c3IDSJ7Uy2FPr8TZ8jP qwRkHWxRJeVnmuZhg6AqOnlTWr4IzjiucVSA8TdEkaULep8lDTnM5pNJd+8CY5Y9EgpP 3UKdB/LhKBdHmKyx64DwCQKq0d7SwMKy2/pcLUyoHf3dhnS8YXp9wjsMLGdHjiJwu1yL IEHNrgOIyzAswe8k/7oEVK5QkfSkgcdN4uJIoxOr+AldknoGIEyHcvEk1XerZW5lnEOi 6HXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RdC8zdeMkDnxJigRR5i6H1m668be4V9/Va0O0I6r5Yk=; b=fAQ3JTXvoWmP+d4Oz6q+gm+7yDZuKMWlWblSjlZzw0US7ZFSqXOwNEGQ8Y4DEn+Fbk h4B2AMItfDy8/+Tn7IDXzRKQdEGaNaMjt8LHOZiBRuFroQSOOq0aesZE4oEkB+PHgwhR wTVo5Js7MBl55JgS/D+BabRdf4Sag4vj9RybOjIzJ/4MD0pxzlA0gJGisJx0Y0EMgV/E X4Ec0HdVOzD5n4OKlP9MsDt4pbOj0XhAGqqZOMyqPaX2rbuYG/MLXaUHzcaZGW4avXPP jrrbdnIIOEDG4H1lCNgz051TJp+u8iyCh+K27trXByjVLA+/GImPs3IvcT3MN9jIZ9Qk 8hfg== X-Gm-Message-State: ABuFfogPzgYX9Ud8zlJsvx/Z4Ei98Wni2H2CSsIPY7IsLlG0RNjda9ND Gi6C3NS6YB8aLy38OgzUm6hLNIimO1fnGvrUNGJqQw== X-Google-Smtp-Source: ACcGV62lAWCZeNnVk9U0ZoVEZYDUXlKBXjMrJOOAY4RRcQynz16gjfcLX8h3YcH9BrxUFyHZ/dDqDqv55KRwunxWLUE= X-Received: by 2002:a9d:7a7:: with SMTP id 36-v6mr1197418oto.337.1538204081978; Fri, 28 Sep 2018 23:54:41 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::32d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230126 Archived-At: --000000000000e600e00576fd0b5b Content-Type: text/plain; charset="UTF-8" +emacs-devel ---------- Forwarded message --------- From: yyoncho Date: Sat, Sep 29, 2018 at 12:39 AM Subject: Re: Running process filters in another thread To: 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 wrote: > > From: yyoncho > > 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? > --000000000000e600e00576fd0b5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+emacs-devel

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


Hi Eli,=

Thanks for the quick response!

Excuse me if I am talking nonsense - my understanding is that there are Em= acs threads(the threads that are available using elisp=C2=A0code) which run= cooperatively and there are OS level threads which for example read the ou= tput=C2=A0of a process and then pass it to the filter function as a=C2=A0st= ring and they might run in parallel and I was talking about running the pre= -filter function into such thread.=C2=A0

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

<= /div>
Alternatively, I was thinking about creating some faster emacs sp= ecific binary serialization/deserialization of data structures so elisp pro= grammers could move the parsing into separate emacs instance(ala=C2=A0https://gi= thub.com/jwiegley/emacs-async) and then consume the output.=C2=A0
=

Thanks,
Ivan

On Sat, Sep 29, 2018 at 12:14 AM Eli= Zaretskii <eliz@gnu.o= rg> wrote:
> From: yyonch= o <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 probab= ly 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 Java= script world.

Emacs threads are cooperative, and only one thread can run at any
given time.=C2=A0 So it i's unclear to me how running process filters i= n 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?
--000000000000e600e00576fd0b5b--