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 09:50:01 +0300 Message-ID: <834jmeew2u.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87pm57pns8.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.fsf@localhost> <831qhli14t.fsf@gnu.org> <87wmzdxewc.fsf@localhost> <83r0plgjeo.fsf@gnu.org> <87o7kpxapo.fsf@localhost> <83mt09gcaf.fsf@gnu.org> <87wmzbc3af.fsf@localhost> <83cz13g811.fsf@gnu.org> <87lefrbvjw.fsf@localhost> <83h6qfecxt.fsf@gnu.org> <875y6vbiej.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16511"; 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 08:50:49 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 1qI1mK-00045M-CY for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 08:50:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI1lX-0003nE-Tn; Sat, 08 Jul 2023 02:49:59 -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 1qI1lW-0003mr-3I for emacs-devel@gnu.org; Sat, 08 Jul 2023 02:49:58 -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 1qI1lV-000644-QU; Sat, 08 Jul 2023 02:49:57 -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=FnYlZvYMIoVvYEzpiZIQ5nPCwxRo+qvdsDQJyuZZPtY=; b=CEfCJ+VRJm3x ZkhFR0SwG2kwH/Mwjev91mP5FLS8jTubcTfJh93wTvaO5bT86uB4TQF8O8BOmziZ7Bd2v9sOgo/Na ayIptrvH6mNFcuukumnyyvnz/wuQEmFf73S6ptMxgI4xT/EL805Rz4Mb8oLf3BYBMaWUHEfM9zKIE hDZykNbJoiYGY//KJv+NV01caWN7Qu+X7VNrCqMzUNvpdCWI6ob9UaKMGzbhXlj2FqtmhF0Q9dBTd D1tER9QG3HoF22+uSFetQ+qzF8bjmsTmRpCT1RKW/3x1/XthiTP+/gcGQG77UCEP1vZvfr3euMA66 H1VF3OOtOcWlyyHVfcMBqQ==; 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 1qI1lV-0002HS-92; Sat, 08 Jul 2023 02:49:57 -0400 In-Reply-To: <875y6vbiej.fsf@localhost> (message from Ihor Radchenko on Fri, 07 Jul 2023 20:01:24 +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:307598 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Fri, 07 Jul 2023 20:01:24 +0000 > > Eli Zaretskii writes: > > >> AFAIU, Elisp memory management is conceptually single-threaded. > > > > Again, I don't understand why you say that and what you mean by that. > > We just call malloc, and malloc on modern systems is thread-safe. > > Does it mean that we can safely call, for example, Fcons asynchronously? Not necessarily, because Fcons is not just about allocating memory. I think we once again have a misunderstanding here, because when you say "memory allocation" you mean something very different than I do, which is a call to malloc to get more memory from the system. It sounds like you think that Fcons _is_ memory allocation? But if so, this terminology is so confusing that it is not useful in a detailed technical discussion such as this one. We use the term "consing" to refer to creation of Lisp objects, which includes memory allocation, but also other stuff. In particular, consing modifies memory blocks (already available to Emacs, so no "memory allocation" per se) used to keep track of live and dead Lisp objects, and those modifications cannot be concurrently done by more than one thread, at least in some cases. > (I am saying the above because my understanding is limited, hoping that > you can give some pointers when I happen to be wrong.) I'm happy to give pointers, once I understand pointers to what. Before I have a chance of understanding that, we need to have a common terminology, though. > >> > buffer-alist > >> > >> I do not see how this is a problem to lock/unlock this variable. > > > > So your solution to each such problem is to lock variables? If so, > > you will end up locking a lot of them, and how is this different from > > using the global lock we do today with Lisp threads? > > The idea is to prevent simultaneous write, which will only lock for a > small fraction of time. If one thread writes to a data structure, reading from it could also need to block, or else the reader will risk getting inconsistent data. So this is not just about simultaneous writing, it's much more general. > And I still fail to see where base-buffer is _changed_. Is base buffer > ever supposed to be changed? Another thread might change it while this thread examines it. > >> > buffer's undo-list > >> > >> That's just a synchronization between old_buffer and > >> old_buffer->base_buffer. > >> I am not 100% sure why it is necessary to be done this way and manually > >> instead of making undo-list values in indirect buffers point to base > >> buffer. > > > > So you are now saying that code which worked in Emacs for decades does > > unnecessary stuff, and should be removed or ignored? > > No, I am saying that the current logic of updating the undo-list will not work > when multiple async threads are involved. It will no longer be safe to > assume that we can safely update undo-list right before/after switching > current_buffer. > > So, I asked if an alternative approach could be used instead. Undo records changes in text properties and markers, and those are different in the indirect buffers from the base buffers. Does this explain why we cannot simply point to the base buffer? If this is clear, then what other approach except locking do you suggest for that? > >> I admit that I do not understand what the following comment is talking > >> about: > >> > >> /* Look down buffer's list of local Lisp variables > >> to find and update any that forward into C variables. */ > > > > The C code accesses some buffer-local variables via Vfoo_bar C > > variables. Those need to be updated when the current buffer changes. > > Now, when you explained this, it is also a big problem. Such C variables > are a global state that needs to be kept up to date. Async will break > the existing logic of these updates. Exactly. > >> > buffer's point and begv/zv markers > >> > >> AFAIU, these store the last point position and narrowing state. > >> I do not see much problem here, except a need to lock these variables > >> while writing them. They will not affect PT, BEGZ, and ZV in other > >> threads, even if those operate on the same buffer now. > > > > Oh, yes, they will: see fetch_buffer_markers, called by > > set_buffer_internal_2. > > Do you mean that in the existing cooperative Elisp threads, if one > thread moves the point and yields to other thread, the other thread will > be left with point in the same position (arbitrary, from the point of > view of this other thread)? That's one problem, yes. There are others. Emacs Lisp uses point, both explicitly and implicitly, all over the board. It is unthinkable that a thread will find point not in a place where it last moved it. > >> > buffer's marker list > >> > >> May you point me where it is? > > > > In fetch_buffer_markers. Again, I don't understand how you missed > > that. > > Is it buffer's marker list? I thought that you are referring to > BUF_MARKERS, not to PT, BEGV, and ZV. Buffer's marker list are referenced in subroutines of record_buffer_markers.