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: Tue, 25 Jul 2023 15:27:19 +0800 Message-ID: <877cqozc14.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <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> <878rb53dkj.fsf@localhost> <83edkxsclz.fsf@gnu.org> <87tttt1mzh.fsf@localhost> <83351ds9de.fsf@gnu.org> <87ila91j6n.fsf@localhost> <83y1j5qoyo.fsf@gnu.org> <87wmypi7s0.fsf@localhost> <87fs5czvs2.fsf@yahoo.com> <87mszk7glc.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="2190"; 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 Tue Jul 25 09:28:45 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from [209.51.188.17] (helo=lists.gnu.org) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qOCTM-0000M5-8k for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 09:28:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOCSI-0007CV-JU; Tue, 25 Jul 2023 03:27:38 -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 1qOCSG-0007CN-NC for emacs-devel@gnu.org; Tue, 25 Jul 2023 03:27:36 -0400 Original-Received: from sonic316-22.consmr.mail.ne1.yahoo.com ([66.163.187.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qOCSE-0006aQ-Ls for emacs-devel@gnu.org; Tue, 25 Jul 2023 03:27:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690270052; bh=pdqi8Vu0ro44stBuByo0JltAACIKPA42zeDS7HkRcRo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=MebxI3n3lfRbdXagDHAjGVUCxoGjUrJ99GHlCcwZHqlbmPVzHCkid090wBqhaGcsFRpnOb60A+IuI6d4mPrZcl2ijsI3/ZrgvgQ2una6V+WKruoxLaPeblWfxzMRs6K+hoouWUUkxrifbNDIy7Hplx4YJqR+UNjyACT5Qu8Azsx/awHRbFcF5rDgIF23AMjkU/tObwkGlHJT5YEIgaHehrS+men6IJw9snPe47MGMCK6gfcaPn0/Mj7gPCAqUkNhooiOrmMCcu4DVrghjDRsxaMxLXpD0bjc4Q2wN/p72xoOzxRTlccaKoZWYiwMpT26fGEY/6Y/C+XbX1nZXkgTBA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690270052; bh=BZprB0mUDc8TqkskRFZRNWCyDFDGJAcOCkFcXTP2MTa=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=pAzvTNJOwm+bZc1ZPuCsyVOg6wlIq692/eiB/W6CRGfjE09AXuaaexWzSglWukHzedwgiMaoBjzo0KjQzdK2QptS416BF7ICkgTkTROTDDPXkdiMSD7QG3+ksV3kk4q2Y9Elm9VvIOcAiTnlKlYzDYs4PpZWRgcdzf10tHpbJwHIc2kq8jLpfJje+QhJDedfAaL64QofyhxxOIbFwwZRRSg+JAvjMii29x1cBhWUrSLNx5YCSrLhDSwYfLOkCJGoyjJsVzIYivCirNyubjUxBddkLVSIApeAev0mH3aHBfG8bc0D2rDhEIgc69ExvNznVe1wgyQpJFSQFxbpYlrKcA== X-YMail-OSG: 5QPE9TsVM1nJPlgYUcuqeyfZSssPPBO3TalFhZIsxfXQX503V4WHuuyn70wGDfd VQ9_SrwaFf8qTTYhLh84yemlrsUz1EMzxXrx_QDUyKgiaxpzYHRpMXtPhXoXkmM2QSNmIcZCiGdz BJmJM8p3EK3CIRrv6mdaTLEoC63mdVY2kWlGumT5CxcAXoT7y79P4.Y5RtqkV1bmKC1YE5L_kqZf kEYKS1wGKpjvZlThZ.qx.af8y29P_3R1hPsxHmIx4x6gw86OLjRzJZmGCfKOp_6__fG1B2qdq.OI atQ7ZKdXAi0qiZFi.NS3kijBJvp5jg5XEqK4TYdJLtkIk1okSBUHSJsNL71Gd0iIDPVWC_fdJpWU NF3AhRGhpPScQ0YVQCpChg.4EKA5.BbRvNMNe.lUb0wa_3tHn7zFUtfKamZnevXBnI3TwIezClVb 8Eyh3cDMQ3as9bov.XvkkzsRTHXkMh3UxnS358MWtdF9F.RogIt7Y0j0BugHYDDV5TlS9pn.Q.o8 UZxn0IqNN2EsorrWr_zjvQA3zNvr3fS52wSf3Idc3zJ0k0QVVrP_VitbyGT4_64EGzszKJQO5SFh WEWwH54D7GlVEB3YGhPbrD3NltyQA17YpUvhjMEu.8L_eo6nVjX69lzlIYyVbnPmAoEG4d_sUGuG cXv2oXZ0uoc0GEWGuUyg4eQf7UcPb_pXWg0I9rJv2lNT2j0P5HeB7iHZjy9reDONxxjXfXZNkass ncjh3c43X7MxkXse4Ki7mAzjZj_YyUJATiVEPSI9Mol962RTB8AIreQNdn5wU_IhE63Y9gLyA55F red7vgmwbXXU9xnzYgFJ4hzURtp2re4uNCZPZ9F.Vh X-Sonic-MF: X-Sonic-ID: 1dee25cf-c02a-4270-87a1-e5c50fc6993e Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Tue, 25 Jul 2023 07:27:32 +0000 Original-Received: by hermes--production-sg3-6b8fc8d58f-875mb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID aa03c78e580c3e441dd094a8bbc71cb9; Tue, 25 Jul 2023 07:27:25 +0000 (UTC) In-Reply-To: <87mszk7glc.fsf@localhost> (Ihor Radchenko's message of "Tue, 25 Jul 2023 04:36:15 +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.187.148; envelope-from=luangruo@yahoo.com; helo=sonic316-22.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=ham 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:308076 Archived-At: Ihor Radchenko writes: > This is a dangerous assumption. > What if Emacs decides to support such architecture in future? No such architecture is likely to run Emacs in the future, because it will fail to support every single piece of multiprocessing software written up to now. And if Emacs does need to support such an architecture in the future (which is a very long shot), we can revisit our choices then. Until that time, I see no need to slow down reads and writes to conses or vectors with interlocking on the basis of purely theoretical considerations. > Simultaneous write and read generally has undefined outcome Only the order in which the reads and writes appear to take place is undefined. Provided that only valid Lisp_Objects are written, no invalid Lisp_Object will ever be read. >, unless we use READ_ONCE and WRITE_ONCE. Emacs is not the Linux kernel and is not subject to its considerations. Besides, READ_ONCE and WRITE_ONCE involve _NO_ interlocking! > There are known architectures where simultaneous read may result in > mixing bits from the old and new values. Which architectures would that be? Unless you're describing unaligned reads and writes, or for data types larger or smaller (on the 21064) than a machine word.