From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Running process filters in another thread Date: Sat, 29 Sep 2018 11:15:01 +0300 Message-ID: <83tvm867p6.fsf@gnu.org> References: NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1538208857 30067 195.159.176.226 (29 Sep 2018 08:14:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 08:14:17 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: yyoncho Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 29 10:14:13 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 1g6AOD-0007ia-12 for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 10:14:13 +0200 Original-Received: from localhost ([::1]:49907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6AQJ-0006pC-HA for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 04:16:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6APH-0006oq-KJ for emacs-devel@gnu.org; Sat, 29 Sep 2018 04:15:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6APC-0003wt-Ni for emacs-devel@gnu.org; Sat, 29 Sep 2018 04:15:19 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6APC-0003wl-Je; Sat, 29 Sep 2018 04:15:14 -0400 Original-Received: from [176.228.60.248] (port=1107 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g6APC-0006nQ-79; Sat, 29 Sep 2018 04:15:14 -0400 In-reply-to: (message from yyoncho on Sat, 29 Sep 2018 10:35:19 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:230130 Archived-At: > From: yyoncho > Date: Sat, 29 Sep 2018 10:35:19 +0300 > Cc: emacs-devel@gnu.org > > 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.