From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Tue, 25 Jul 2023 09:03:58 +0000 Message-ID: <87tttsqs5d.fsf@localhost> References: <871qhnr4ty.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> <877cqozc14.fsf@yahoo.com> <87bkg0s9p4.fsf@localhost> <87351cz993.fsf@yahoo.com> <87wmyoqt0j.fsf@localhost> <87y1j4xtgr.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38640"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 25 11:04:40 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 1qODyC-0009la-MI for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 11:04:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qODxQ-0006ia-S7; Tue, 25 Jul 2023 05:03:52 -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 1qODxP-0006iE-5O for emacs-devel@gnu.org; Tue, 25 Jul 2023 05:03:51 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qODxM-00006X-NM for emacs-devel@gnu.org; Tue, 25 Jul 2023 05:03:50 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 20FA1240101 for ; Tue, 25 Jul 2023 11:03:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690275826; bh=KnlIbompHVsjgSDDAaEddtcUhL3mqiAvXeNJIBROUZg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=bdfQG2tiWVYqTMsGRtpl2tknD8q70HTewuh2KXiv9HGQuNmGWNuGtVBiw3dgetlqm jo8jTvisHnB03AKKL9PjthCyCM/cBKx1khMa7fhSJ56YaI63SByJsiE0mEwgKRzUcj f4yY8ldcBzx+zxo2f+7+rMo6yRVezqQ0yZAiT9VkA87bbD0RBSz6/NFtW1QzByJNqP 3c8QVigQp9kfnz0QzHKfnGofMnFnQa05OwzJdpSKYiWhRDF2/Y7AMA2mbxJ6yT3WMK F3P8KsxUmoAsjN7VHSfw7jI2pP1mLZJNT9rbz53nhj1kXxUdurNch8QzQmznbrSZaj ANKczL812v1JA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R9B0K0rvWz6tvp; Tue, 25 Jul 2023 11:03:44 +0200 (CEST) In-Reply-To: <87y1j4xtgr.fsf@yahoo.com> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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:308082 Archived-At: Po Lu writes: >> I understood that figure and the associated section differently. >> Do you have some kind of reference showing the performance of >> READ_ONCE/WRITE_ONCE? > > The figure is titled ``Figure 5.1: Atomic Increment Scalability on > x86''. The surrounding text and source code listings make the > comparison taking place unambiguous. Sure, but the whole chapter design shows that READ_ONCE/WRITE_ONCE is not the best design. They go deep and complex just to avoid using it too much. That said, the chapter is dealing with increments specifically and frequent writes. In Elisp, we will deal with frequent writes into symbol objects, but probably not into conses and other non-vectorlike objects. >> If we need less interlocks, it will certainly make things easier, but I >> do not want to run into hard-to-debug bugs caused by data races. > > And you won't, if you run your program on a machine Emacs currently > supports. Ok. I will take your word for granted. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at