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: Sat, 08 Jul 2023 10:05:17 +0300 Message-ID: <83351yevde.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87ilax71wo.fsf@localhost> <878rbtkz2c.fsf@yahoo.com> <87a5w96x2o.fsf@localhost> <87jzvdjjp4.fsf@yahoo.com> <877crd6w53.fsf@localhost> <877crdjiwn.fsf@yahoo.com> <874jmh6v4s.fsf@localhost> <83y1jtgmbw.fsf@gnu.org> <87zg49xfke.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11363"; 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 Sat Jul 08 09:06: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 1qI21D-0002iv-OU for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 09:06:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI20L-0000Vl-1n; Sat, 08 Jul 2023 03:05:18 -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 1qI20J-0000VV-TH for emacs-devel@gnu.org; Sat, 08 Jul 2023 03:05:16 -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 1qI20J-0004MZ-GU; Sat, 08 Jul 2023 03:05:15 -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=Q2UyGGxu2L5XD1TmwqrjD85JrDhKYJPLf3qlJbE62MA=; b=VQm+eJVX15V3 tEs+VdfGoh4Nl0gWZFngKRhAHMsv9X/Z/sxu0OHJBEKgWdqVNX4FbHmJO6u9SgZpC77OIsOi0QhHw zjsxoRjuK5OQn/NYOHl01y8qx/rDG3VEBOTV6id0fum4Rpwm9gXOdY/MjWN1Mljmy8/E9PuK+4I8Y K7Px+UeJV0FjFBYSt5q/fZuTabXXEUUlc1zJSbstI5lzSzPqOuP4nmxrSpVwS1oxxwi7f4msZqYWN Fd1pgfoCnBwGUmRYI+hLTysustc6D8uLdJIfxoxfhCIQJAy03TkBgpk1/WbcgyTHunPd1gMOGudfl p4nQ51I1W/EANnlyoDbs8Q==; 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 1qI20I-0006lT-Cz; Sat, 08 Jul 2023 03:05:15 -0400 In-Reply-To: <87351zbi72.fsf@localhost> (message from Ihor Radchenko on Fri, 07 Jul 2023 20:05:53 +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:307599 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Fri, 07 Jul 2023 20:05:53 +0000 > > Eli Zaretskii writes: > > >> But how exactly does, say, relocating buffer text can break things? May > >> you provide a pseudo-code example? > > > > ... If you > > consider allowing relocation when the buffer is locked, then some of > > the threads will be surprised when they try to resume accessing the > > buffer text. > > Can you please provide an example about "surprised"? Do you mean that > buffer->pt will no longer be accurate? Something else? Not pt but the pointers to buffer text and the gap. Those determine the address of a given buffer position in memory, and are used when a Lisp program accesses buffer text in any way. GC can change them if it decides to relocate buffer text or compact the gap. > >> Then the question is: can the global state be reduced? > > > > By what measures? Please suggest something concrete here. > > By transforming some of the global state variables into thread-local > variables. Which variables can safely and usefully be made thread-local? I invite you to look at all the defvar's in the ELisp manual that are not buffer-local, and consider whether making them thread-local will make sense, i.e. will still allow you to write useful Lisp programs. (And if we are thinking about more than one thread working on the same buffer, then buffer-local variables are also part of this.) As an exercise, how about finding _one_ variable routinely used in Lisp programs, which you think can be made thread-local? Then let's talk about it. > >> May it be acceptable to have a limited concurrency where async threads > >> are only allowed to modify a portion of the global state? > > > > I don't see how one can write a useful Lisp program with such > > restrictions. > > Pure, side-effect-free functions, for example. I don't see how this could be practically useful. Besides the basic question of whether a useful Lisp program can be written in Emacs using only side-effect-free functions, there's the large body of subroutines and primitives any Lisp program uses to do its job, and how do you know which ones of them are side-effect-free or async-safe? To take just one example which came up in recent discussions, look at string-pixel-width. Or even at string-width.