From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 17 Jul 2023 16:36:35 +0800 Message-ID: <87h6q36ijw.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <87y1jf29a4.fsf@localhost> <878rbf0y6b.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22847"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 17 10:37:21 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qLJjM-0005lK-TX for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Jul 2023 10:37:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLJiw-0007su-Ce; Mon, 17 Jul 2023 04:36:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLJit-0007l9-VU for emacs-devel@gnu.org; Mon, 17 Jul 2023 04:36:52 -0400 Original-Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qLJiq-0008Us-In for emacs-devel@gnu.org; Mon, 17 Jul 2023 04:36:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689583006; bh=y3zLKo9TeQqtMI2NSGyX8NukK4kPK2c23XozpNUy0Do=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=FVoul9Vt2uUdxNuXNyUHReMV8Q5JjXAzSfYQ7FN4w92z196nK80YKgaHXhHf5VNRFua8/W4TJlMp/AYPjEkVFHIR1Psdi7pOQKDMP5E26cmqPv+rw1go/xJzr/V/gOJHEKDwBxLm4A9YH5eLfNDBifB5szRKV0xFsmvIvLTyNHGszRIIcWl3YA5uvDia9n+ayNiMMfGi3fCUV+0UyEJd3EHV4UJ/0HyJ0lg/ayBjeMDSZaEDcL2cVTfH/oKBzVzz/GEwAS/3RkDrdRu699sEdgm0w2ZcIpA78hryC1AHM4b3/urPbpcGoU3kmFqSD71WDg8kyGt8VdQNOkK6UISoPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689583006; bh=nNzenr8nU4kggU01ky9UCBtk+Fxibs3E6IS6T8CJB90=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=SsC0pTv7p1pxj0au6wy/A1DF4EqKQn2amhNLpY8bQN+9nBuLE5O2nyYvySAawBwfLiV0y7ALC4IfILfDjUOi5M6q7i0TTuy8Cl76iZN8Qz5l1umwfWQeB0Vx1PhJPUB5GDWP5tUbmaiuQIiFLuRu8QczXEvdVaMHdmhF0SPChdY7nQFYibmJjnYwY42dQ6iNSN619NNXb+Y1RP2F66A6DnyEHUL2ScyGjVlO8M1shVUQVKZ90GavRBDJPT6DM52xc1iY67wc8K1+MtlZyd7xZOJM1EmBP2bs3B5GxWOI5VyLkYQx7lVZoS9LuZF/fmWvdLcUucuBu/sFqFNk6iXNnw== X-YMail-OSG: YmA2zYMVM1nn_OM_9IZvGpEdaGPMlrEQLsWYsqtmY51VYkJzCTiupcig0L3DcR2 39UDnr1uTS2vojeFC32iptrmSDZMusfIYFb4NU6OmiEnzTmF1VFyj_EkfaNq5ZVPkIs7wACS_NBi 5._W4bHMFWKgOSMzjw_mGx3dMEUd.53VdJzTzj.ZgFN.t7zwOwtTl8bTPirSCVgqSwGy0s0Y1AyD xtP0ep36M_MMC3KvXXjLbxUFfak30mwcdKAFpuZsyhnrs13aFk9MK9b3XvM5aH_Hmyh3kWeBAEQb _PHEOknYBBDo5YWPn_5zAzn.dh3qG5mhJVansBf0PFqt3E256mlksWjtUI9JIoyjqjSs_2khOf8Q A2XqLRCeC3wUrgxudzvCgj2EU8IU1.jLn3YahjVQtuWInIhMixUQibf.MdWy70UGqFiV5jfHbNbW k90p4HQF2adPs.V5.ACPlpNWUiMFKSDZP0Gb213QvA2CYCDA1LsS8QtKvMmktxxfeQjfluhKOJXT 8Ukfn9icJ0Sm_T3HjnmFZdJIntr2IeVaPzt912PrYgEN4ivMp37CDb6ZSP4.f0E4T5nztvGreYDy CdVDkwvTlyUmfykaYCIYxuOD0QZcCr8S29RHW5nlzHzVw3vyRAFMjSte1ObSvkZXZobYtyH1BHIJ XsTIGXxBfMluS1_4g_M7LTs0RR.ZwsNRDOfS7KG0aO7tGNTDpc9Xt_Eot3.qXzbpcytu2TeWY7B5 KeLzvWAO8iFy4vN94km2V.bmRcDz1Cyc6kb9t2wkfpNNTX58eaY9TjrWD4e7lRTx9syfkKoBc_i0 vgKNO8rYV_8qstTESAGr9ZlGVg7_PfQFRh6Sm4DlC7 X-Sonic-MF: X-Sonic-ID: bcb8bed9-5fdc-425c-bee9-f1509da77b54 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Mon, 17 Jul 2023 08:36:46 +0000 Original-Received: by hermes--production-sg3-67fd64777-z82qw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 69fed54beb62be0c371291c387e91ed9; Mon, 17 Jul 2023 08:36:41 +0000 (UTC) In-Reply-To: <878rbf0y6b.fsf@localhost> (Ihor Radchenko's message of "Mon, 17 Jul 2023 07:55:40 +0000") X-Mailer: WebService/1.1.21647 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.200; envelope-from=luangruo@yahoo.com; helo=sonic301-31.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307917 Archived-At: Ihor Radchenko writes: > I can see several ways to approach this: > > 1. We can maintain a separate, sparse (just for changed variables) > obarray inside threads, so that `intern' > will point to thread-local symbol objects. Interning happens at read (and thus load) time. Byte-code vectors and lambdas given to make-thread contain symbols, and not their names. A thread-local obarray will not be helpful. > 2. Force lexical scope inside threads, so that the values do not have to > be stored in object value slots, but within per-thread lexical scope > structure. > This however, will not work when using things like `cl-letf' where > Elisp code may want to temporarily set symbol function slots. This is not realistic. > 3. Store multiple value and function slots in symbol objects. Why would this be difficult? It would slow down accesses to value and function slots (especially those which aren't bound dynamically), but that's an unavoidable drawback of multiprocessing.