From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: HaiJun Zhang Newsgroups: gmane.emacs.bugs Subject: bug#38807: [Feature request]: Support lisp workers like web workers. Date: Sun, 29 Mar 2020 10:41:51 +0800 Message-ID: References: <83o8vpn8g1.fsf@gnu.org> <87mub9u0ld.fsf@gmx.de> <831rslmxih.fsf@gnu.org> <83lfqslafm.fsf@gnu.org> <83r20jjgg3.fsf@gnu.org> <83png1hyb8.fsf@gnu.org> <83imlrh9ze.fsf@gnu.org> <83d096dswz.fsf@gnu.org> <83lfnscvfi.fsf@gnu.org> <831rphbyuw.fsf@gnu.org> <837dz79nvh.fsf@gnu.org> <87v9mrkmot.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="5e800af4_4b683d0d_6dce" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="90683"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38807@debbugs.gnu.org, michael.albinus@gmx.de To: Eli Zaretskii , Ivan Yonchovski Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 30 04:38:15 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIkJa-000NUw-PS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Mar 2020 04:38:14 +0200 Original-Received: from localhost ([::1]:43784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIkJZ-00071p-RA for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Mar 2020 22:38:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55029) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIkHu-0003oF-Mi for bug-gnu-emacs@gnu.org; Sun, 29 Mar 2020 22:36:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIkHt-0003hD-9W for bug-gnu-emacs@gnu.org; Sun, 29 Mar 2020 22:36:30 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48649) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jIkHt-0003gw-4o for bug-gnu-emacs@gnu.org; Sun, 29 Mar 2020 22:36:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jIkHt-0004is-1e for bug-gnu-emacs@gnu.org; Sun, 29 Mar 2020 22:36:29 -0400 X-Loop: help-debbugs@gnu.org Resent-From: HaiJun Zhang Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Mar 2020 02:36:28 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38807 X-GNU-PR-Package: emacs Original-Received: via spool by 38807-submit@debbugs.gnu.org id=B38807.158553573517423 (code B ref 38807); Mon, 30 Mar 2020 02:36:28 +0000 Original-Received: (at 38807) by debbugs.gnu.org; 30 Mar 2020 02:35:35 +0000 Original-Received: from mail-oln040092253015.outbound.protection.outlook.com ([40.92.253.15]:43776 helo=APC01-SG2-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jINtq-00087s-36 for 38807@debbugs.gnu.org; Sat, 28 Mar 2020 22:42:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WUnG6jzdTivggs32Esld9QbFdcoqYGJlNo0c8OgMbF0hOqVe0rk+bm6QJUP8MIdc9qkHx+3HkW/6t1El/15Dvz7V1qhqW+LMRZmD6297YGQpd/51xX2LrINUWLktU7vIRphyINKP91+3J5Kr/LfPG43Zuy37bEydEMVFWmq9XmiYeDk+8FOfkolkUqwBuQuisho4aW7ZD6SzgQ080Bcv5n9UgEKXzQKfSOiejHL27yonbLUGa7I7g/UlIBb9OOdjxezCekLcpFCmNr5N0b7oPvY32ofaAgdrDw/vXY6AC19+vWGO1yytfSJm/XPkZd2WgRvbPXOMP2gOLuUf2DYMlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VYM0NvkK+IrPratg65s9eOxPi+LcTg/kwdVEMfHj0EI=; b=M75F+andNv+9kiQVxV7xjzFXfkAX8VFim6iFP6ANK9cAMPQI/9pZXQN8xCw0xCwz6LwL3Cl2QUHdxTqLZxOir221UGBZSCkXaW/O8Lk7Xk1lZRSvouRxS2XckE52J5ZgM2buWAasg89kmlDkjJfxBknpusY8XzduhoJ5GqMYZWKtUm568KAxMW04cppazbvs896gxkv+P8VhgBPD5ziZYaKIK25t+PLPyEsX02OM3s63IW2VzZexpUuZPY8S6XAeLz24OLLebRxt9hTAkgzsiWK5AQ4YqM83/BEBcpw4Y0ENucBPtf2Cm6oCQ/YZYLM0jYZOiz1LYigZhKB4j50+Ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=outlook.com; dmarc=pass action=none header.from=outlook.com; dkim=pass header.d=outlook.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VYM0NvkK+IrPratg65s9eOxPi+LcTg/kwdVEMfHj0EI=; b=U2QZ0KOGJSmVyBPZi8MZf+wqRJoXO7/dWaLev6ZbcJ7sBmk2rfpd3jrPGqG/bK/wu23Is0qGjm5T6PwIYAoyjTSuP9BqvPuAmdIats5nrcrw42RfDRmq4F+muDlkQueAohQTfVPQEXsR0bcwJ2/o+eBkMR3BmRE7YmXoo2H7jTAZpDs0ICgxUyQocaCQ03HcjkPYT0EW0w2XhXD2wmUSQSwKuHysrILPMY1maDDQaFQca70pbYEqUXEE0PhY4H0Lra2SV94w2A/g4P3KYvFGgqEdg3l9/DZmQ0StHSkCtpUe69pf7v3YU7iqr/HjwvTSdC3kCIQCX8A4LGhtRzw6ow== Original-Received: from PU1APC01FT050.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::42) by PU1APC01HT079.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::289) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17; Sun, 29 Mar 2020 02:42:01 +0000 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com (10.152.252.58) by PU1APC01FT050.mail.protection.outlook.com (10.152.253.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Sun, 29 Mar 2020 02:42:01 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:63F94F2C4F5263F9BCCD72C277963734631A4D85C07D6A9325488AF35447571C; UpperCasedChecksum:8BB7BD438ED198C0E384DD4BB6952D43DA4819D54B275433E55055FE629D3D6A; SizeAsReceived:9870; Count:49 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::85cb:c430:1173:7716]) by PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::85cb:c430:1173:7716%5]) with mapi id 15.20.2878.013; Sun, 29 Mar 2020 02:42:01 +0000 In-Reply-To: <87v9mrkmot.fsf@gmail.com> X-Readdle-Message-ID: e8a54047-bd09-4762-bba4-296ff74cfda5@Spark X-ClientProxiedBy: HK2PR02CA0129.apcprd02.prod.outlook.com (2603:1096:202:16::13) To PS1PR03MB3606.apcprd03.prod.outlook.com (2603:1096:803:4e::17) X-Microsoft-Original-Message-ID: X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from [192.168.1.150] (1.196.186.57) by HK2PR02CA0129.apcprd02.prod.outlook.com (2603:1096:202:16::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18 via Frontend Transport; Sun, 29 Mar 2020 02:42:00 +0000 X-Readdle-Message-ID: e8a54047-bd09-4762-bba4-296ff74cfda5@Spark X-Microsoft-Original-Message-ID: X-TMN: [ZQexG7ysY+mmZT9DyY4qwFqIzrNEj3em] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: e226a4a0-91a6-4ca3-48b9-08d7d38ac25a X-MS-TrafficTypeDiagnostic: PU1APC01HT079: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9eSU6WC51BXPcI4K1jnGyUMnv0vxi5C83hKAwyUMWMvfPgb8K0KR4UbSvWKBYXtH0aVIKlEWKei1CRzQZ7yMdykTN3LqbSNLdIrwZDR1/Z0xftP8q7Ao8QIU7MH4jFpDbTzRogRKdks3335Tk+em+pKIdVI3BvYoyZ9xfe2ovhamJGM8bBve/w+MTvm5AbYD X-MS-Exchange-AntiSpam-MessageData: ogXy8/QeTPwQMVNKLSVTUSG+5cD0MVafWh2KA1vPgPi1CUJF5EDkYoOybBMGlWfUQX8pxzE++I3GJHlcisloIuQb3vNIGdlEZthRiHuxnNpaoewYnmyQBhOboCXyT8b0XA/rS0UCbEQ4x4HYJXeQhQ== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e226a4a0-91a6-4ca3-48b9-08d7d38ac25a X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2020 02:42:01.8087 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT079 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-List-Received-Date: Sun, 29 Mar 2020 02:42:12 -0000 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:177846 Archived-At: --5e800af4_4b683d0d_6dce Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2020=E5=B9=B43=E6=9C=8827=E6=97=A5 +0800 AM2:15=EF=BC=8CIvan Yo= nchovski =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > > Eli Zaretskii writes: > > > Since the user waits for this job to finish anyway, why does it help > > to run some of this processing in a separate thread=3F > > The user might not want to wait for the completion but he/she might wan= t > to continue to type while the parsing is taking place. The effect is > that the typing feels slugish. IME with latest native json parsing this= > is no longer the case for lsp-mode. > > > With my limited understanding of emacs internals I see 2 potential > solutions to allow writing of =22lisp workers=22. > > 1. Start second(or multiple) elisp interpreter in the emacs process > which has thread local copy of all of the global data(buffers, data > allocation, etc). It may or may not have a gui attached to it. In > addition to that, introduce primitives for moving elisp datastructure > from the background thread to the main UI thread and vice versa > eventually by coping the original structure to avoid bugs. > I=E2=80=99d like not expose any global data to them. Even the data alloca= tion can be standalone. Then they pass lisp object by coping as you said.= > 2. Make the functions that create elisp datastructures threadsafe(or > some sane subset) and expose them to the dynamic modules. > > Thanks, > Ivan --5e800af4_4b683d0d_6dce Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=E5=9C=A8 2020=E5=B9=B43=E6=9C=8827=E6=97= =A5 +0800 AM2:15=EF=BC=8CIvan Yonchovski <yyoncho@gmail.com>=EF= =BC=8C=E5=86=99=E9=81=93=EF=BC=9A

Eli Zaretskii writes:

Since the user waits f= or this job to finish anyway, why does it help
to run some of this processing in a separate thread?

The user might not want to wait for the completion but he/she might want to continue to type while the parsing is taking place. The effect is
that the typing feels slugish. IME with latest native json parsing this
is no longer the case for lsp-mode.


With my limited understanding of emacs internals I see 2 potential
solutions to allow writing of "lisp workers".

1. Start second(or multiple) elisp interpreter in the emacs process
which has thread local copy of all of the global data(buffers, data
allocation, etc). It may or may not have a gui attached to it. In
addition to that, introduce primitives for moving elisp datastructure
from the background thread to the main UI thread and vice versa
eventually by coping the original structure to avoid bugs.


I=E2=80=99d like not expose any global data to them. Even= the data allocation can be standalone. Then they pass lisp object by copin= g as you said.

2. Make the functions = that create elisp datastructures threadsafe(or
some sane subset) and expose them to the dynamic modules.

Thanks,
Ivan
--5e800af4_4b683d0d_6dce--