From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: HaiJun Zhang Newsgroups: gmane.emacs.bugs Subject: bug#38807: [Feature request]: Support lisp workers like web workers. Date: Wed, 1 Jan 2020 11:47:49 +0800 Message-ID: References: <83o8vpn8g1.fsf@gnu.org> <87mub9u0ld.fsf@gmx.de> <831rslmxih.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="5e0c166b_697d2d2_4379" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="204208"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "38807@debbugs.gnu.org" <38807@debbugs.gnu.org> To: Michael Albinus , Eli Zaretskii , arthur miller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 01 04:49:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1imV0R-000qwh-55 for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Jan 2020 04:49:11 +0100 Original-Received: from localhost ([::1]:48126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imV0Q-0007Gy-2g for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Dec 2019 22:49:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36124) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imV0K-0007Gs-2X for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2019 22:49:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imV0I-0002Rl-8r for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2019 22:49:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57701) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1imV0I-0002Ql-3j for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2019 22:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1imV0I-0006ZV-2y for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2019 22:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: HaiJun Zhang Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Jan 2020 03:49:02 +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.157785049425188 (code B ref 38807); Wed, 01 Jan 2020 03:49:02 +0000 Original-Received: (at 38807) by debbugs.gnu.org; 1 Jan 2020 03:48:14 +0000 Original-Received: from localhost ([127.0.0.1]:35441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1imUzS-0006Y9-LG for submit@debbugs.gnu.org; Tue, 31 Dec 2019 22:48:14 -0500 Original-Received: from mail-oln040092254061.outbound.protection.outlook.com ([40.92.254.61]:15904 helo=APC01-PU1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1imUzO-0006XW-Qx for 38807@debbugs.gnu.org; Tue, 31 Dec 2019 22:48:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nMU5xzqZ0J4w0VGSOnvriT4RNvBFLL90OMZ7hYcOZBg6tLPRHa7whQSEmgFNf5ws0I5N7j9bRzVIhUl0zN3f3Q81V+O15ZLfKsLr32lZ9+GN+lNO7xT42FxJqzfdW/zfV+SiWxgH7YHaYKMWRjuoV16K8L9c2ommNTlfPUZEeAXa8ypN3Zle7YrV8Dg3kPukBZndcDw4BfQQjt9e7Wlztbz0K3ACowBbhHnssSMmutupl+2PWBKY1xNfxRBllmcLDVGypn0vhgpIguhmYlqr1HPcFG4YlAyldPNSC5rG3Joui8F74GlSzrupEQERdi13kI4Vftn0Q3I45KMIJUnKpQ== 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=UGxyT2xkhk0IclaPZrN6XuDpY5z6cQNyqvqOFbrz46k=; b=P/oBUKnLUpXLVILIULKzW0LURm3Nmn/qikF5T0E8URTqzzNZc8nH2ER8QsZU+tzDyKKYYS8m3ELxBYYGwP+4RZEGIyhfASVlu3U8DYyGkDwWQ995914roTkWqUBMMNjTVSXKhpjT7zheWet9OidPFHVgxpDb3y4J1V9OIybK44bGok08fltaY3SVnU2maIJ1iRkLD9h7HtkdtDyItPN0VDHErtiL9534Mwphib0tyuthKkTz8738tkNbUJfF/oaFZqDK3mmcgWSIuOJkUSgKeTMfvac/9KMvgi/zaJG7gZK4ZN/hCSdKhbwH1oiu+SOAdOJHWCio3DYg3Kng/e5alg== 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=UGxyT2xkhk0IclaPZrN6XuDpY5z6cQNyqvqOFbrz46k=; b=MBhHmnE63WFlWhQNMx8f6A4APl4fFEMhA3AznA4RV4hAMqKcwc5VQOwjOE1SKohXmPbL4pBxqpPt/hkxwyosIr7ZaZ8KiwM441aq46sb5ySlYnddtvWBgs1ZMAVFOWXWszyORSfwIYwsXVgtqgEoOnpx9YY6ArHJtDCNPDB4cZJwPayOQRVEVyNTK4ubGHtTU+A2UjH4rcm848M5wMdFqAJJt6+Htdl4RpE55EDmDSmadmHuI8WMEMKu+Tmcpn1SB0r/SnMXmIUG40Ua8wND0Ut5RWoRwzqKLgr+rfHMzykGGy05oQ79EYyN6gT30/jWYbfdGacSMqSjTG/BUN2NYg== Original-Received: from HK2APC01FT020.eop-APC01.prod.protection.outlook.com (10.152.248.56) by HK2APC01HT099.eop-APC01.prod.protection.outlook.com (10.152.248.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Wed, 1 Jan 2020 03:47:58 +0000 Original-Received: from SG2PR03MB3611.apcprd03.prod.outlook.com (10.152.248.53) by HK2APC01FT020.mail.protection.outlook.com (10.152.248.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Wed, 1 Jan 2020 03:47:58 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:80003C02E5B89274C18DAFD78153224599F36DB7D6B7EA8645D482ECECA8B916; UpperCasedChecksum:5E965962E496EB01C0F68F7AFCB149FF61176E74408F1E216D24AEC3648C03D3; SizeAsReceived:9201; Count:48 Original-Received: from SG2PR03MB3611.apcprd03.prod.outlook.com ([fe80::65f4:d979:9d3d:1829]) by SG2PR03MB3611.apcprd03.prod.outlook.com ([fe80::65f4:d979:9d3d:1829%7]) with mapi id 15.20.2602.010; Wed, 1 Jan 2020 03:47:58 +0000 In-Reply-To: X-Readdle-Message-ID: 08aee9fb-f0e7-483e-bba8-6dc367a0f2e4@Spark X-ClientProxiedBy: HK2PR03CA0048.apcprd03.prod.outlook.com (2603:1096:202:17::18) To SG2PR03MB3611.apcprd03.prod.outlook.com (2603:1096:4:17::11) X-Microsoft-Original-Message-ID: <08aee9fb-f0e7-483e-bba8-6dc367a0f2e4@Spark> Original-Received: from [192.168.1.103] (1.193.170.223) by HK2PR03CA0048.apcprd03.prod.outlook.com (2603:1096:202:17::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.7 via Frontend Transport; Wed, 1 Jan 2020 03:47:57 +0000 X-Readdle-Message-ID: 08aee9fb-f0e7-483e-bba8-6dc367a0f2e4@Spark X-Microsoft-Original-Message-ID: <08aee9fb-f0e7-483e-bba8-6dc367a0f2e4@Spark> X-TMN: [EBgazr8TBE88RmMHafwOIQwazmF/3h3y] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 7a46d346-7f17-4b2b-4876-08d78e6d6466 X-MS-Exchange-SLBlob-MailProps: mBRmoEB1kyJZ8Cjv+npDeE0mb0JtgErRqozdCqtio5kgYxQEdTHv9nkZuukLtBs3r3QfPP2WrOwlOm4G6LpncqQ/M3ArPub44IpDi3QHZ8DIcGnVcOOM8Zj3VdVPXN4gJoITlBp9CjJbSOoWEvy20EPiCOQ4rgHIIBpqYkoBZnjqqnKrpH2ydbnlIPGuSUJgjDytp96wQFT1RLkfeojc+f1tY3D0a/Hu2nvvJ34Fg2R2J5CUY1+qF6rWi8dkoXlKYfmz7TNcjA2pCa8TOYntAevt5ldawJOxwT32zIn8c2ITbk5P60ANX0Hv/NGGf3GuRWILQ9AUYDOUlAXf0+YsIh1+4+/ILT6V9rYt0XrhibVJPRlNit9oZjZkl/F7rEEKCTyGvk4r98oaQbiQCzv0tulU6LzL0WAkGzulkw+iBUIvIHwHOAPCNvpcVjCtMrVirRMCBNcHK6rmLbzbD1851j1qQ/tfkaE3GgxAUeuaYnC9ABmXrr+4uk1lDCJ1xG7Yj0nEVmT+zkfhTkgsoogOLOFxSga4zmK/KXfI82f640Y2ZKjki/bxTA2cyCZ5apcOfEDyn5bwS7+OFYAFoBqaLKuH3fyAIOUyJznE9lg/joGFkfsnYZvyMS6atw25cZUZ0kzbNLB7VbL9ZrDahtVHEOqzLvFXT/FgeP2FoVgihWhyoPZBMJI25JviVWvsuPSEclIH0hBtS9XjixIocC0qzFGOeXm33b0pxw8ndwF4XFmB/SKSnm6YglkWNbk2Dztz x8tsBSP9IOE= X-MS-TrafficTypeDiagnostic: HK2APC01HT099: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IpSHDx+kGWjgNzUaMPRsAJldlc0zOpGAa2oA/JnCoatYd7CvVyXP0gXxZ5Sxloul+yDbQp0EQAH79ucKm4zHYC6wG2PsA7e64YZjK9sWWzWsGucAqkaqL5ozAsRPDcVbOzkMFB9lCORCXWzMFrN+piTSBhAV0fWXk0ODd2aPbObZ4ucA1mZU/EjOqaKU2q5h X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a46d346-7f17-4b2b-4876-08d78e6d6466 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jan 2020 03:47:58.5407 (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: HK2APC01HT099 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174011 Archived-At: --5e0c166b_697d2d2_4379 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline My understanding of the display flow: 1. an event comes which causes redisplay 2. the display engine prepares the glyph matrix 3. convert the glyph matrix to bitmap and display it I think lots of work are in 2. During the work in 2, the display code nee= ds to access many resources in lisp machine and even may eval lisp forms.= The resources it accesses are too wildcard, so that we can't copy the re= sources to it and put them to queue. =46or multi-threading, we need a glo= bal lock. =E5=9C=A8 2019=E5=B9=B412=E6=9C=8831=E6=97=A5 +0800 AM9:39=EF=BC=8Carthur= miller =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > Cool idea. > > I have a question.=C2=A0 Is it even necessary for lisp machine to contr= ol UI=3F > > Couldn't lisp machine post its =22ui events=22 to a some kind of render= queue and maybe input queue, instead of drawing and handling stuff immed= iately in an OS window=3F That could decouple drawing from the rest and c= ould open for some other interesting stuff when it comes for rendering. > > I don't know maybe another thread for input queue. Probably too much wo= rk and I really don't know if that would be possible with Emacs architect= ure, at least as of current. > > I mean does lisp machine really need to know where it draws=3F It could= as well just =22draw=22 some events to a queue which could be rendered a= way in different passes, by different threads and so on. > > Skickat fr=C3=A5n min Samsung Galaxy-smartphone. > > > > -------- Originalmeddelande -------- > =46r=C3=A5n: HaiJun Zhang > Datum: 2019-12-31 01:42 (GMT+01:00) > Till: Michael Albinus , Eli Zaretskii > Kopia: 38807=40debbugs.gnu.org > =C3=84mne: bug=2338807: =5B=46eature request=5D: Support lisp workers l= ike web workers. > > =E5=9C=A8 2019=E5=B9=B412=E6=9C=8831=E6=97=A5 +0800 AM3:19=EF=BC=8CEli = Zaretskii =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > > > =46rom: Michael Albinus > > > Cc: HaiJun Zhang , 38807=40debbugs.gnu.org > > > Date: Mon, 30 Dec 2019 19:31:26 +0100 > > > > > > The point seems to be that there is a dedicated UI thread. That we = don't > > > have (yet) in Emacs, and I like this idea. > > > > We do have that on MS-Windows. Except that you'll be surprised how > > much of =22UI=22 in Emacs cannot be done in a separate thread, mainly= > > because the Lisp machine is under such complete control of what the U= I > > does, and you cannot run several instances of the Lisp machine > > simultaneously and asynchronously. > > What about the following idea: > 1. Make the current lisp machine be customized which has two profiles: > =C2=A0 =C2=A0 + full featured: as the current running lisp machine in e= macs > =C2=A0 =C2=A0 + subset one: without all UI functions > 2. Run the full featured one as emacs does now. It acts as the master l= isp machine(for UI only), which behave like the UI thread(process) in the= web browser. > 3. Run some subset ones for workers. Workers are started by the master = lisp machine. Workers can send messages to the master machine by calling = some APIs. The messages are copied to the master lisp machine, so GCs don= =E2=80=99t need to work across machines. > 4. Provide some APIs for them to communicate with each other. > --5e0c166b_697d2d2_4379 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
My understanding of the display flow:
1. an event comes which causes redisplay
2. the display engine prepares the glyph matrix
3. convert the glyph matrix to bitmap and display= it

I think lots of work are in 2. During the work in= 2, the display code needs to access many resources in lisp machine and eve= n may eval lisp forms. The resources it accesses are too wildcard, so that = we can't copy the resources to it and put them to queue. For multi-threadin= g, we need a global lock.

=E5=9C=A8 2019=E5=B9=B412=E6=9C=8831=E6=97=A5 +0800 AM9:39=EF= =BC=8Carthur miller <arthur.miller@live.com>=EF=BC=8C=E5=86=99=E9=81= =93=EF=BC=9A
Cool idea.

I have a question.  Is it even necessary for lisp ma= chine to control UI?

Couldn't lisp machine post its "ui events" to a= some kind of render queue and maybe input queue, instead of drawing and ha= ndling stuff immediately in an OS window? That could decouple drawing from = the rest and could open for some other interesting stuff when it comes for = rendering. 

I don't know maybe another thread for input queue. Probab= ly too much work and I really don't know if that would be possible with Ema= cs architecture, at least as of current. 

I mean does lisp machine really need to know where it dra= ws? It could as well just "draw" some events to a queue which cou= ld be rendered away in different passes, by different threads and so on.

Skickat fr=C3=A5n = min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Fr=C3=A5n: HaiJun Zhang <netjune@outlook.com>
Datum: 2019-12-31 01:42 (GMT+01:00)
Till: Michael Albinus <michael.albinus@gmx.de>, Eli Zaretskii &l= t;eliz@gnu.org>
Kopia: 38807@debbugs.gnu.org
=C3=84mne: bug#38807: [Feature request]: Support lisp workers like web= workers.

=E5=9C=A8 2019=E5=B9=B412=E6=9C=8831=E6= =97=A5 +0800 AM3:19=EF=BC=8CEli Zaretskii <eliz@gnu.org>=EF=BC=8C= =E5=86=99=E9=81=93=EF=BC=9A
From: Michael Albinus = <michael.albinus@gmx.de>
Cc: HaiJun Zhang <netjune@outlook.com>, 38807@debbugs.gnu.org
Date: Mon, 30 Dec 2019 19:31:26 +0100

The point seems to be that there is a dedicated UI thread. That we don't have (yet) in Emacs, and I like this idea.

We do have that on MS-Windows. Except that you'll be surprised how
much of "UI" in Emacs cannot be done in a separate thread, mainly=
because the Lisp machine is under such complete control of what the UI
does, and you cannot run several instances of the Lisp machine
simultaneously and asynchronously. 

What about the following idea:
1. Make the current lisp machine be customized which has two profiles:=
    + full featured: as the current running lisp machine= in emacs
    + subset one: without all UI functions
2. Run the full featured one as emacs does now. It acts as the master = lisp machine(for UI only), which behave like the UI thread(process) in the = web browser.
3. Run some subset ones for workers. Workers are started by the master= lisp machine. Workers can send messages to the master machine by calling s= ome APIs. The messages are copied to the master lisp machine, so GCs don=E2= =80=99t need to work across machines.
4. Provide some APIs for them to communicate with each other.

--5e0c166b_697d2d2_4379--