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 11:52:32 +0000 Message-ID: <871qgwnr7j.fsf@localhost> References: <871qhnr4ty.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> <83cz0gqlee.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37350"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 25 13:53:23 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 1qOGbT-0009Vk-1D for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 13:53:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOGaY-0006uu-L1; Tue, 25 Jul 2023 07:52:26 -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 1qOGaW-0006ui-Rf for emacs-devel@gnu.org; Tue, 25 Jul 2023 07:52:24 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qOGaU-0002K8-5W for emacs-devel@gnu.org; Tue, 25 Jul 2023 07:52:24 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 47125240028 for ; Tue, 25 Jul 2023 13:52:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690285940; bh=QHmD9GqdUcxjSarPBifAMMD2vLgAMWur0IxJCEmaIcI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=FJucfMSM9uhfkH4srYsMdp8MC2h4NHsBaLsjLHg5uCN+QIsmJklga8HS+jcE6mLBw qws33XlM/ZNm/7069VSaUCuxcmmSFBipQBfKllDNjqlOGeVqVQJ0fzxNcaDFkd80Vx vIkXn7Fbt6EX2ksdiIl7PE1u4B5ucR25D+shAmhKttI3Xj38bkNP8qysYdiMGfZwfB JzpzVUjSUpQ07rtC3jQhtP7qQfogFi5zuWxfA+bFLLZPD/diRVJOtqfCLOloRaM+zD MYfoJJ/+huEK5LMNPthw7M1i6jkXbeXIpbeDvuWvjMIBMcGnOBZAya+xOfO1wNFJcn rWPIhaTrDz2cQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R9Fkq4Gkfz6tw7; Tue, 25 Jul 2023 13:52:19 +0200 (CEST) In-Reply-To: <83cz0gqlee.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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:308091 Archived-At: Eli Zaretskii writes: >> Any async thread should expect that current buffer might be modified. > > That's impossible without rewriting a lot of code. And even after > that, how is a thread supposed to "expect" such changes, when they can > happen at any point in the Lisp program execution? What kind of > measures can a Lisp program take to 'expect" that? The only one that > I could think of is to copy the entire buffer to another one, and work > on that. (Which is also not fool-proof.) >> Of course, such write locks should happen for short periods of time to >> be efficient. > > How can this be done in practice? Suppose a Lisp program needs to > access some object, so it locks it. When will it be able to release > the lock, except after it is basically done? because accessing an > object is not contiguous: you access it, then do something else, then > access it again, etc. -- and assume that the object will not change > between successive accesses. If you release the lock after each > individual access, that assumption will be false, and all bets are off > again. This is just a basic problem with any kind of async code. It should either (1) lock the shared object it works with to prevent async writing (not async reading though); (2) copy the shared object value and work with the copy; (3) Design the code logic taking into account the possibility that any shared object might change any time. All 3 approaches may be combined. >> Or lock the buffer for text modifications explicitly (the feature we >> should probably provide - something more enforcing compared to >> read-only-mode we have now). > > Locking while accessing a buffer would in practice mean only one > thread can access a given buffer at the same time. Which is what I > suggested to begin with, but you said you didn't want to give up. Not necessary. Multiple threads may still read the buffer in parallel, except special case when read also involves moving the gap (being written at low level). Or are you saying that moving the gap by read primitives is common? >> So, any time we need a guarantee that an object remains unchanged, we >> should acquire object-specific write-preventing mutex. > > So we will allow access to many/all objects to only one thread at a > time. Only when modifying global objects by side-effect. Like `setcar' or `move-marker', or `puthash' (on shared objects). And only for the duration of that modification. I do not think that "many/all" objects will be locked in practice. Symbol objects will be treated separately, with value slot storing multiple values for different threads. (This is necessary because of how specpdl and rewind works for symbols) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at