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 08:20:45 +0800 Message-ID: <87fs5czvs2.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <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> <878rb53dkj.fsf@localhost> <83edkxsclz.fsf@gnu.org> <87tttt1mzh.fsf@localhost> <83351ds9de.fsf@gnu.org> <87ila91j6n.fsf@localhost> <83y1j5qoyo.fsf@gnu.org> <87wmypi7s0.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="4026"; 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 02:22:12 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 1qO5oa-0000oo-BQ for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 02:22:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qO5na-0004jt-QP; Mon, 24 Jul 2023 20:21:10 -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 1qO5nY-0004j7-Jk for emacs-devel@gnu.org; Mon, 24 Jul 2023 20:21:08 -0400 Original-Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qO5nR-00068H-Ly for emacs-devel@gnu.org; Mon, 24 Jul 2023 20:21:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690244457; bh=EDGRz/CLAuKZsmdMxbfx4nNZl+BGjuTRy3Irm+wnTug=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=flsQK9qI9Z/vbzaRztuHMhHHYjO8prnq1CMvXjFpPcYURwZ122KgSUvXgELPU52qJNuxZ/rzdvVxiwUov4VK+rXNkymtMj8HT74YNANEOd5BiOKx6nYSXS7NhcGJJBkc8tRlwMgvxYZKYsVhF7CHcOzj1n5n0kM8it2wThlEvOe4s91zC6PxWqNazyRPzvAK+aQeEKsrOzWVPToB7/O9bwP7p0TBGv/MiPZfxbPSFnCJdAMKHEVsytgrl7IvYdIljKCmN50gwXWMpho97u99Py+Rge/AZAx3p8vN0MS+I4o+4wWoJLW7jseJL5ewT+8qvDr1nn0ECG/TzItQBJv9nQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690244457; bh=5VDhdpo008qR5FmGG/9vqQeqwYxP64ZPowV5HH/uuTL=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=DD8tmMkVPV24RGRgToTiZcm5Pmv/9TrlDW1qZi0qruLWKCKYD9uWLxOs9KhimSdhKdcvFDiw65nQ5BIMZfiN79MDA4LQ4bZKrj5XOXY6ZtSjevxBwpIhOMlGZJlJCioRYJhQ28+bpm+BkQPa6s9CMMVXG3vpyd8IPgp7P6HaLYXecIGCwW+enTbAWSV8n+HBjn/FF4cibYeMvEJVzjLegc538IU/ovKsrLvUg3XnsXiybZpvRxd7ciBJfOW/MfwRvNe9zFVffmcx+iguwBYX4+R3tHhyhlLq1vrotuizMegBZW6oNgmeiWguq8XN9nfP5kCaXQ2kWubKYcPcNUc8vg== X-YMail-OSG: dfSUD2IVM1n2zt_.lAx47fc5Szlq18zfk5DyJVZvPDFe7GrIjJaZ3JTcEkDmP1s Svnhgagsm2kWPz74DdZ6ISJ8lJsUuMawq.XH9.2QFnykrQQqprbCYpZDFGMu1.Geu9eez_qUqArD VN2.tdKAhC8vawaEypvAqxbnwEcjfHgcxM1Dl1dHhLnwJOVZGiOw85gzAaZ1Y23lT8nryaLDwijp r9Qah3NmZj4Mrxmq1T3WlIuXL6Vwo52iojXLR4DG5PCEP1UnDaCE4gDA2wws6b9S3zqzrKayH9WZ QQNPN6wsIUkXJC0VUHlUXZRIIseIFZju3ZNPPFXkwj0NmH.KyJ18lWNb_lG99tqGkHNJXCXiD2eq Cgw65u114FgbBQRa482hcMCCcCrkzOY6pKDq3LeUmAzSdUz0Tn0c110Ue9w6_ZLe8uy6u7jrqRYp brdP6W_v9bkSEA3FJ2b1N13v5kaolDljltIBbOoCDwL956x_91X8t._rTC3wEe2QE4w2KsuE9e6h _zRn6cRDT.oUZ7e5zevT34pHbXpL.2jPxD8ayyicMMOeZ7fuTMG_QjwhNTnLJDMkLcprFKDjWJ1z W.B_qXL6tP6yadqSPyD5SEjL46HzJj_Q.wzKsX7IQYfkX.F3tGiLo1ZQ3L_jmosFhD1G5lg_b_xI xgf1VetpGzfTlak7UcQVMkEZg1BC5cYwlzxhFv6vR2Em06cyIqIWMCGTpj6dR8uiHyfPCfbXhNW9 HRBeFKwdPGlbEOBtEg9RAhPxDSEDFWIHv77e_RDykqLVISKMPiMQPgoXY26ebrUutRPZfalx4r.k Z1EDSDapxRnpoMBolXiqViJ.8TMCoJ.hnRT9m4aCJ6 X-Sonic-MF: X-Sonic-ID: d5df79c8-1eb1-43d3-9066-8d410bcd3926 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Tue, 25 Jul 2023 00:20:57 +0000 Original-Received: by hermes--production-sg3-6b8fc8d58f-zs8lh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cabe459ee2451a479e1b01a014602fc7; Tue, 25 Jul 2023 00:20:50 +0000 (UTC) In-Reply-To: <87wmypi7s0.fsf@localhost> (Ihor Radchenko's message of "Mon, 24 Jul 2023 16:38:55 +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.148; envelope-from=luangruo@yahoo.com; helo=sonic309-22.consmr.mail.ne1.yahoo.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=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=no 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:308069 Archived-At: Ihor Radchenko writes: > This problem is not limited to buffers - any low-level function that > modifies C object struct must enforce the condition when other threads > cannot modify the same object. For example SETCAR will have to mark the > modified object non-writable first, set its car, and release the lock. No, because reading the car of a Lisp_Cons does not depend on any other field within the Lisp_Cons. No interlocking is required to read from or write to machine word-sized fields, as changes to such fields are always propagated coherently to other CPUs. At worst, you will need to flush the write cache on any CPU that has written to one such field. (Even these machines are rare -- I don't think Emacs currently supports any.) Interlocking is only required when correctly interpreting the value of one field requires the state of other field(s) to be the same as when the first field was set. For example, PT and PT_BYTE must always be interlocked: a thread must not see one value of PT and then read an earlier or later PT_BYTE corresponding to a different value.