From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 24 Jul 2023 19:00:31 +0300 Message-ID: <83y1j5qoyo.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4858"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 24 18:01:07 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 1qNxzf-00017Z-5E for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 18:01:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNxyR-0001Ju-Nq; Mon, 24 Jul 2023 11:59:51 -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 1qNxyQ-0001Ji-Bd for emacs-devel@gnu.org; Mon, 24 Jul 2023 11:59:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNxyP-00029Y-9e; Mon, 24 Jul 2023 11:59:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dh0k7ugsw05cpMHnq48LQ6TzVWUEyXIPYHM/2rD2HSw=; b=IlgEYfdrYD2N 8q13JsbR7zqxb/NXhnsivQm+2rlisjxQl/Iuj+rSomRcczhxdH8WR3X5sCDVLWZIMp4Km114YRJG3 xwutXU3aCnHCaHHUKJIJL2qqgSFQfAhQpaVzRM70EA3MweYVcncPxfbW2xDH+eBCrgfaxUZ8aWHoK VodERPzzG6m/iUBRDReBIxWdEhnGWDQS614vQwXYA8CEO+R6RDV0zRyLpDe3+LhJ5dNqe2MWmicEG seuzQeq/kRl/Qd/EVVArmI2aBejfhxXKglwVQGe+XMVWY9pZDfBLC5zDyHMtorGY7bPX6T2oL/Nm+ k3V9SE/XYhQgwcFaEskD3w==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNxyO-0002my-Oy; Mon, 24 Jul 2023 11:59:49 -0400 In-Reply-To: <87ila91j6n.fsf@localhost> (message from Ihor Radchenko on Mon, 24 Jul 2023 14:24:32 +0000) 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:308063 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Mon, 24 Jul 2023 14:24:32 +0000 > > Eli Zaretskii writes: > > > So the goal is to eventually support true concurrency in Emacs? > > Yes. OK, thanks. > > ... so these steps only make sense if the > > concurrency is attainable via these measures? > > Yes, except that the part about thread-local point and restriction may > be more generally useful. I suggest to forget that latter part: we have a "generally useful" code already, so changing it without a very good reason is not wise, from where I stand. > > You are considering just the simplest scenario. Usually, Lisp > > programs in Emacs not only read text, they also write and delete it. > > What if one thread makes changes to buffer text and another thread > > then wants to access it using its state variables? E.g., what do you > > plan doing about the gap? will thread switch move the gap or > > something? that alone is a performance killer. > > 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. > We only need to move the gap when buffer is changed or before copying > text region from buffer to another buffer. Both such operations should > be considered buffer modifications and must be blocking. > > > To be a step in the general direction of achieving concurrency, we > > need some plan that will at least in principle allow concurrent > > editing. Even if "concurrent" here means that only one thread can > > write to a buffer at a time, we still need to see how this will work > > when other threads are unblocked once the writer thread is done > > writing. Can you describe how this will work, assuming we keep the > > current design of buffer with a gap? > > The idea is the same as with what is already done for indirect buffers. > Indirect buffer modification will affect buffer_text object in the > base buffer (automatically - buffer_text object is shared). And they > will also affect point position in the base buffer. > > 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. 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. 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?