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: Sat, 4 Jan 2020 14:41:58 +0800 Message-ID: References: <83o8vpn8g1.fsf@gnu.org> <87mub9u0ld.fsf@gmx.de> <831rslmxih.fsf@gnu.org> <83lfqslafm.fsf@gnu.org> <83r20jjgg3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="5e1033bb_6f0939f8_4379" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="265127"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "38807@debbugs.gnu.org" <38807@debbugs.gnu.org>, "michael.albinus@gmx.de" To: Eli Zaretskii , arthur miller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 04 07:43:20 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 1ind9b-0016o2-38 for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jan 2020 07:43:19 +0100 Original-Received: from localhost ([::1]:60066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ind9a-0004EO-0z for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jan 2020 01:43:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40534) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ind9N-0004E5-Mq for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2020 01:43:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ind9L-0003b5-MQ for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2020 01:43:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36430) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ind9K-0003aK-4Y for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2020 01:43:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ind9K-0004SC-1e for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2020 01:43: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: Sat, 04 Jan 2020 06:43:01 +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.157812014717064 (code B ref 38807); Sat, 04 Jan 2020 06:43:01 +0000 Original-Received: (at 38807) by debbugs.gnu.org; 4 Jan 2020 06:42:27 +0000 Original-Received: from localhost ([127.0.0.1]:42403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ind8g-0004R2-DC for submit@debbugs.gnu.org; Sat, 04 Jan 2020 01:42:27 -0500 Original-Received: from mail-oln040092255073.outbound.protection.outlook.com ([40.92.255.73]:4096 helo=APC01-HK2-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ind8d-0004Qg-IK for 38807@debbugs.gnu.org; Sat, 04 Jan 2020 01:42:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=et4++AURNZ4AvDYy/6cxKGRJzufyiWTVyXjJSKhk8jdtxctfe/JVwgvemaw9/M0w6cfjP7yE9Ymj+A8xDHHu87YWZPawllJyNGyzrKpnL8KDwK4DU7gSHtIDM8IyRWOvqbbausYKBntaSQMS5xjpJk0+bc+vcBAGV+EwqFfOv8M275CZ/657b8zQhXk04twmKifRKJqklrEinjEevfo9e5qiWIjycyeMvQnDNEkMzFdWueRXhD43GdhVryEvB+qNypvfqznWGIpdK5Lk5AvtpRcqt5+916wjHkmLtqagnmFNXZTDpF9vfmsDApZaYEJ1dxXHIZel2VbKYinzP7R5OA== 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=dnVlRZOY80CzyELq0c3D7AtSsFYk6EAmcMljTpLPSWA=; b=jrjkOa9PxEuxO2p+eL5CrobBedOc62PEFfStHExlWyxraJty29iaf8xaEbgeB9djuMkcpJxZqHVdMuc2fLE4YTAn5yCmxv5m0XxK7vsbgWz/4FyFZRKVRUsBz6s5RNSsjURB3P+1/U6FtGurm+8pfayCTUBiq9RCM8iUNdtazDoDVbojukHTIfYvJougWwzWt+ob8NKlMQqWjbLfAXGOZ4DwfrxztqcduvLwOEHjDnqBhaMKaCNEWa4AMd6Znm5PWbqC382AfmIlPNCuUmLAKAUflwREqxbtmaxC+T2d9QM5X3sM1ohvS7DgJZ8meCn6HDidIgkzti5jpqrsE3KLvQ== 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=dnVlRZOY80CzyELq0c3D7AtSsFYk6EAmcMljTpLPSWA=; b=oKEgKu8SwS25GSBl/tB3Tj2SwRSZWp2JTbKXLZmY2lGn++7z/mwuXZlo07ZLgmM8G60ml6rfsPyTsU6Yb6QX9hZdOtyUrD758hUMisd8mtZMBDD3lXvkUD28Y6bbHdviYaRgxfGe9B7HAqOCehThK9sCaMfo3LjAqZ1CWBQAMjnHxR5Qw9GyIV3lMSKgldOwPG3OkcpwJAvhR5d31Lq1vMpJ2FYNd9wbJVcMj346TKvYq3lvoGJTLvhrlTogwSC217L/P+VDlAVDWCafkaoM+ClZ+YmKD/fT+L0XdBGFa9PQGA7iRfCZTPeQ8yVWqLrT9mwlq+WyUE57ZnQ+KscvlA== Original-Received: from PU1APC01FT026.eop-APC01.prod.protection.outlook.com (10.152.252.57) by PU1APC01HT101.eop-APC01.prod.protection.outlook.com (10.152.253.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Sat, 4 Jan 2020 06:42:10 +0000 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com (10.152.252.51) by PU1APC01FT026.mail.protection.outlook.com (10.152.252.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Sat, 4 Jan 2020 06:42:10 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:95A149B52C5AD142C5620562D77D551A89720FC84AA7D6790A6981F2D8B31961; UpperCasedChecksum:FC3776A76B0FBE5824D86BAB80E7037359F35F2A06E7E1773E55114783C7DAE3; SizeAsReceived:9450; Count:48 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::b470:80bc:efed:9117]) by PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::b470:80bc:efed:9117%7]) with mapi id 15.20.2623.002; Sat, 4 Jan 2020 06:42:10 +0000 In-Reply-To: X-Readdle-Message-ID: c5f867e5-2599-4c95-9082-ca1565106924@Spark X-ClientProxiedBy: HK0PR03CA0112.apcprd03.prod.outlook.com (2603:1096:203:b0::28) To PS1PR03MB3606.apcprd03.prod.outlook.com (2603:1096:803:4e::17) X-Microsoft-Original-Message-ID: Original-Received: from [192.168.1.103] (1.199.245.197) by HK0PR03CA0112.apcprd03.prod.outlook.com (2603:1096:203:b0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12 via Frontend Transport; Sat, 4 Jan 2020 06:42:06 +0000 X-Readdle-Message-ID: c5f867e5-2599-4c95-9082-ca1565106924@Spark X-Microsoft-Original-Message-ID: X-TMN: [BObC+rcdDmyGoES8S7d9/TBq5juDXxon] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: a0314f9f-15c6-41e2-1db8-08d790e1398b X-MS-Exchange-SLBlob-MailProps: 7FNIAzWC7TpQE0WUgx7fnFiBCYfaxZF7jwYy+iZ74Xfu8Vagj6dYBCIjCtgiqDhZbgQOT1sxAio420eYRlSME8YalA1jLJUZCDZDbupui6h3CvK9Rskq957+aGwZmrCNIuCK3z7813MZ1tLo530MqxmNlwVX9lr4bOCoxj03eemCScmxnN1t2oLAl97LAL42j8qwps2lE89zsdS2KhaLPlhyZDiwacvP6gThgsT6QBzaOnNj3JLZq7lm1TcrcYmz/uCsqKXkwJD2qopkSNtaKzbAM6mZ+p/qW5RHQMExTgs0vHasfDsTYV/5ocsCLHtM3NBLMMfjJCk9ggAGkObZU4zQURu/TodhTx3Hbr5M4+4Dp42lwBrYYVVg/bI5TOD3BCbGQmIygGC1mRiuJrjo0xbWCgsDkmIF5G1nZutREZrJSQd21uwbObrobF1AJH7JmojD0ZEXKYcs1q6XwhbEFhUW00YB6SqKAhb6Q0TqROz8WrOA4MIxOpr1XAlkHEC/NRkT3vGGBJ4uh/Hw2t7gLHuTlR8Va4R2kYzlJSOMxArEOdxn0lBWMO8uHgtwzwdOw4CT3pN2AtXRhAKLSqCzC1UlgZaFESp5T+FfeV5JDKlYE4ZO531YZrFPH5+iAeqyK2mwB0nfEiMgpSFnxOBQ7NdrkiepJTD1ZboUWo8cURtT3qWTk9voHuebadu7+5rgioVIvd1iCuyNODWLZacNteLIxkLlhSZR/qhHNipBYv/mLyf2Kxuy5BGPFLyFSffW YTZTt4g4y/ddIzx2J9YNrzFlY7Ha4u8QitSdnxsR+TLTNj9MwtH4A058QTFuOU+cTus54WCVYiltTPhwc9qZl2josu4tdjQooG X-MS-TrafficTypeDiagnostic: PU1APC01HT101: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1CrBq9k854P/DSHjXLGxOgmAVAg6UOwHnxBsZ5YKD7vZBSANCDQyN2rYFLTsZB44fw6feZNacAHb5HIFB2V8f/Gn+phi0xS091n/wp7Ltk7AfFDqSxxvt652gemtyzjjAAvN4XCTumLdSBxozTh28y306iZ8sJgwtfwXVLwQ6yVuhHcjp2HDzJNY0m6rPQAGZE2Lky4pspiOZTAJ9RfByaH4w0zWwbyTXqrcsBh5jMs= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0314f9f-15c6-41e2-1db8-08d790e1398b X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2020 06:42:10.6802 (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: PU1APC01HT101 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:174148 Archived-At: --5e1033bb_6f0939f8_4379 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Workers don=E2=80=99t have to be in dedicated native threads. It is decid= ed by the lisp machine if they are run in a lisp machine. =E5=9C=A8 2020=E5=B9=B41=E6=9C=883=E6=97=A5 +0800 PM10:11=EF=BC=8Carthur = miller =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > As a concept, I am not sure a thread is the best solution to implement = for a high level scripting runtime as Emacs lisp. Thread is a relatively = primitive concept and leaves a lot to=C2=A0 applications programmer to de= cide and manage. In concurrent programming a thread is OK-ish concept, bu= t it might not be the best for truly parallel problem solving. > > Creating more threads than there are physical cpus creates overhead tha= t might eat up benefits of parallelism. It=C2=A0 also forces a programmer= to think in terms of machine, scheduling, synchronization etc. It can be= more effective and more lisp-ish to think in terms of tasks and let the = core manage the threads and scheduling on it's own. > > Tasks let us think about the work we wish to perform and not how to per= form it. It lets runtime create number of worker threads and schedule the= m automatically instead of forcing programmers to join, synchronize etc > > As a concept a web worker is just a worker thread introduced as idea in= various single threaded gui toolkits long ago. Java's Swing popularized = worker threads heavily back in days, and I don't remember if M=46C also m= ade a deal of those before Swing or after. > > Anyway, these were just ordinary threads,=C2=A0 doing some work, like p= opulating big lists and similar, nothing special. However back in days th= reads were cheap. Everything run on one CPU, and threaded programming was= mostly what we today call concurrent programming. > > Since Swing and Mfc were big things, we have got multi core CPUs as mai= nstream and threads have got much more expensive to create and communicat= e with. Java threads back at days where super cheap to create. I am not s= ure how expensive are posix threads on different cpus, but I know that wi= n32 threads are quite expensive/slow. =46or a small work it might be more= expensive to process it in separate thread. > > Tasks can be mapped on entire thread or put into a queue for physical t= hreads to pick them up. Thus I think tasks might be more suited for say a= n input queue or render queue and similar. > > If I remember well, certain version of DirectX used to process input in= separate thread, which they abandoned in some later version. However I s= topped to work with dx years ago, before dx10 come out, so I don't know h= ow they do nowadays. > > > Skickat fr=C3=A5n min Samsung Galaxy-smartphone. > > > > -------- Originalmeddelande -------- > =46r=C3=A5n: HaiJun Zhang > Datum: 2020-01-03 04:36 (GMT+01:00) > Till: Eli Zaretskii > Kopia: 38807=40debbugs.gnu.org, michael.albinus=40gmx.de > =C3=84mne: bug=2338807: =5B=46eature request=5D: Support lisp workers l= ike web workers. > > =E5=9C=A8 2020=E5=B9=B41=E6=9C=882=E6=97=A5 +0800 AM12:21=EF=BC=8CEli Z= aretskii =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > > > > Then these threads cannot really run Lisp at all, nor even directly > > affect Lisp data. So in effect you want to be able to run threads > > that don't enter the Lisp interpreter, nor modify any Lisp data. > > =46or web worker, they have different contexts. The following is from M= DN(https://developer.mozilla.org/en-US/docs/Web/API/Web=5FWorkers=5FAPI/U= sing=5Fweb=5Fworkers): > > workers run in another global context that is different from the curren= t=C2=A0window. Thus, using the=C2=A0windowshortcut to get the current glo= bal scope (instead of=C2=A0self) within a=C2=A0Worker=C2=A0will return an= error. > The worker context is represented by a=C2=A0DedicatedWorkerGlobalScope=C2= =A0object in the case of dedicated workers (standard workers that are uti= lized by a single script; shared workers use=C2=A0SharedWorkerGlobalScope= ). A dedicated worker is only accessible from the script that first spawn= ed it, whereas shared workers can be accessed from multiple scripts. > --5e1033bb_6f0939f8_4379 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Workers don=E2=80=99t have to be in dedicated native thre= ads. It is decided by the lisp machine if they are run in a lisp machine.

=E5=9C=A8 2020=E5=B9=B41=E6=9C=883=E6=97=A5 += 0800 PM10:11=EF=BC=8Carthur miller <arthur.miller@live.com>=EF=BC=8C= =E5=86=99=E9=81=93=EF=BC=9A
As a concept, I am not sure a thread is the best solution= to implement for a high level scripting runtime as Emacs lisp. Thread is a= relatively primitive concept and leaves a lot to  applications progra= mmer to decide and manage. In concurrent programming a thread is OK-ish con= cept, but it might not be the best for truly parallel problem solving.

Creating more threads than there are physical cpus create= s overhead that might eat up benefits of parallelism. It  also forces = a programmer to think in terms of machine, scheduling, synchronization etc.= It can be more effective and more lisp-ish to think in terms of tasks and = let the core manage the threads and scheduling on it's own.

Tasks let us think about the work we wish to perform and = not how to perform it. It lets runtime create number of worker threads and = schedule them automatically instead of forcing programmers to join, synchro= nize etc

As a concept a web worker is just a worker thread introdu= ced as idea in various single threaded gui toolkits long ago. Java's Swing = popularized worker threads heavily back in days, and I don't remember if MF= C also made a deal of those before Swing or after.

Anyway, these were just ordinary threads,  doing som= e work, like populating big lists and similar, nothing special. However bac= k in days threads were cheap. Everything run on one CPU, and threaded progr= amming was mostly what we today call concurrent programming. 

Since Swing and Mfc were big things, we have got multi co= re CPUs as mainstream and threads have got much more expensive to create an= d communicate with. Java threads back at days where super cheap to create. = I am not sure how expensive are posix threads on different cpus, but I know= that win32 threads are quite expensive/slow. For a small work it might be = more expensive to process it in separate thread. 

Tasks can be mapped on entire thread or put into a queue = for physical threads to pick them up. Thus I think tasks might be more suit= ed for say an input queue or render queue and similar. 

If I remember well, certain version of DirectX used to pr= ocess input in separate thread, which they abandoned in some later version.= However I stopped to work with dx years ago, before dx10 come out, so I do= n't know how they do nowadays. 


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



-------- Originalmeddelande --------
Fr=C3=A5n: HaiJun Zhang <netjune@outlook.com>
Datum: 2020-01-03 04:36 (GMT+01:00)
Till: Eli Zaretskii <eliz@gnu.org>
Kopia: 38807@debbugs.gnu.org, michael.albinus@gmx.de
=C3=84mne: bug#38807: [Feature request]: Support lisp workers like web= workers.

=E5=9C=A8 2020=E5=B9=B41=E6=9C=882=E6=97= =A5 +0800 AM12:21=EF=BC=8CEli Zaretskii <eliz@gnu.org>=EF=BC=8C= =E5=86=99=E9=81=93=EF=BC=9A

Then these threads cannot really run Lisp at all, nor even directly
affect Lisp data. So in effect you want to be able to run threads
that don't enter the Lisp interpreter, nor modify any Lisp data.  
=

For web worker, they have different contexts. The following is from MD= N(https://developer.mozilla.org/en-US/docs/Web/API/Web_= Workers_API/Using_web_workers):

workers= run in another global context that is different from the current window. Thus, using the window= shortcut to get the current global scope (instead of self) within a Worker will return an error.

The wor= ker context is represented by a DedicatedWorkerGlobalScope&= nbsp;object in the case of dedicated workers (standard workers that are uti= lized by a single script; shared workers use SharedWork= erGlobalScope). A dedicated worker is only accessible from the s= cript that first spawned it, whereas shared workers can be accessed from mu= ltiple scripts.


--5e1033bb_6f0939f8_4379--