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: Fwd: Running process filters in another thread Date: Sat, 29 Sep 2018 10:37:33 +0300 Message-ID: <83va6o69fm.fsf@gnu.org> References: <83bm8h729x.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1538206595 5454 195.159.176.226 (29 Sep 2018 07:36:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 07:36:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: yyoncho Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 29 09:36:31 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 1g69nj-0001LP-Cb for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 09:36:31 +0200 Original-Received: from localhost ([::1]:49830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g69pp-0005Ql-UT for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 03:38:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g69p0-0005Qg-By for emacs-devel@gnu.org; Sat, 29 Sep 2018 03:37:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g69ox-0002lg-7l for emacs-devel@gnu.org; Sat, 29 Sep 2018 03:37:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g69ow-0002lZ-A6; Sat, 29 Sep 2018 03:37:46 -0400 Original-Received: from [176.228.60.248] (port=2350 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g69ov-0006f8-Ty; Sat, 29 Sep 2018 03:37:46 -0400 In-reply-to: (message from yyoncho on Sat, 29 Sep 2018 09:54:30 +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:230129 Archived-At: > From: yyoncho > 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.