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: Mon, 24 Jul 2023 16:38:55 +0000 Message-ID: <87wmypi7s0.fsf@localhost> References: <871qhnr4ty.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> <878rb53dkj.fsf@localhost> <83edkxsclz.fsf@gnu.org> <87tttt1mzh.fsf@localhost> <83351ds9de.fsf@gnu.org> <87ila91j6n.fsf@localhost> <83y1j5qoyo.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="16676"; 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 Mon Jul 24 18:39:51 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 1qNyb9-000458-0l for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 18:39:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNyaF-0005gx-Rx; Mon, 24 Jul 2023 12:38:55 -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 1qNyaE-0005gP-AU for emacs-devel@gnu.org; Mon, 24 Jul 2023 12:38:54 -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 1qNya8-0003WN-8z for emacs-devel@gnu.org; Mon, 24 Jul 2023 12:38:54 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 39907240027 for ; Mon, 24 Jul 2023 18:38:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690216726; bh=/Q7M11Ga+8FDEUPjcUpJGFtQZ8lZ/iWR6d94wcI4ku4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=i7sVZItK62YGZODv73zLmczMQb+O87c5R2n7IWJQWRphWN5E0ZQJLV//iKMQQDv+P +ffd2YTk8Edgs2u2AAFJ2UOgDqJdZipRALjskvgXoydr8zyF5P8PsWK0sSNQJrNU/o DpGpQZ1/TfZeHOUifO2U6asgjxldrQR4Xb4bwG2es54+Pby9el9OeawOFLNSCT6Wm3 UXLZelFJ0rvoAhjLJ44Lqe4d28B7RaOFvCdV5YSRPttzq74Jy9vpTyeRPzMQBjFgkb y6mPsavZdV8E1ByM7saFUOGHCuD+Xf5uPtBA+VbOlrONGTExLvWPsvxwZKFEK/MOYm klrWtdguIawow== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R8m7n481fz6tvx; Mon, 24 Jul 2023 18:38:45 +0200 (CEST) In-Reply-To: <83y1j5qoyo.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, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=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:308064 Archived-At: Eli Zaretskii writes: >> AFAIK, reading buffer does not require moving the gap. > > We've been through that: at least xml.c moves the gap to allow > external libraries access to buffer text as a single contiguous C > string. This is a capability I wouldn't want to lose, because it > might come in handy in future developments. move_gap_both should lock the buffer as it is buffer modification (of the buffer_text object). htmlReadMemory should also lock it because it expects constant string segment. And if we really want xml.c:parse_region to be asynchronous (not blocking other threads reading the same buffer), we can still do it at the cost of extra memcpy into newly allocated contiguous memory segment. >> The point adjustment in the base buffer is done simply by storing point >> as a marker. We can do the same for thread-local point positions. > > I still don't quite see how this will work. Indirect buffers don't > introduce parallelism, and programs that modify indirect buffers > _know_ that the text of the base buffer will also be modified. By > contrast, a thread that has been preempted won't know and won't expect > that. It could, for example, keep buffer positions in simple > variables, not in markers; almost all Lisp programs do that, and use > markers only in very special situations. Any async thread should expect that current buffer might be modified. 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). > In addition, on the C level, some code computes pointers to buffer > text via BYTE_POS_ADDR, and then uses the pointer as any C program > would. If such a thread is suspended, and some other thread modifies > buffer text in the meantime, all those pointers will be invalid, and > we have bugs. So it looks like, if we want to allow concurrent access > to buffers from several threads, we will have a lot of code rewriting > on our hands, and the rewritten code will be less efficient, because > it will have to always access buffer text via buffer positions and > macros like FETCH_BYTE and fetch_char_advance; access through char * > pointers will be lost forever. Not necessarily lost. We should provide facilities to prevent buffer from being modified ("write mutex"). 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. So, any time we need a guarantee that an object remains unchanged, we should acquire object-specific write-preventing mutex. Of course, such write locks should happen for short periods of time to be efficient. Some of the existing uses of BYTE_POS_ADDRS may be converted into explicit dynamic calls to (n < GPT_BYTE ? 0 : GAP_SIZE) + n + BEG_ADDR - BEG_BYTE; If necessary. > So maybe we should take a step back and consider a restriction that > only one thread can access a buffer at any given time? WDYT? Buffers are so central in Emacs that I do not want to give up before we try our best. Alternatively, I can try to look into other global states first and leave async buffer access to later. If we can get rid of the truly global states (which buffer point is not; given that each thread has an exclusive lock on its buffer), we can later come back to per-thread point and restriction. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at