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: Fri, 07 Jul 2023 22:31:10 +0300 Message-ID: <83h6qfecxt.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35748"; 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 Fri Jul 07 21:32:06 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 1qHrBV-00093V-UP for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jul 2023 21:32:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHrAo-0003HL-UZ; Fri, 07 Jul 2023 15:31:23 -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 1qHrAa-0003Gl-M1 for emacs-devel@gnu.org; Fri, 07 Jul 2023 15:31:10 -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 1qHrAZ-0000F4-QK; Fri, 07 Jul 2023 15:31:07 -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=WQKrvkiNjbnXiQMQcnh+QS7lCkZ+qzNu94k7JbYBq3A=; b=LOEk+2rtZOq/ DOC3PWFaWVX45CYZ034sV/L0nPTBA7YyQNXPtlfT1kYjeZcNKKmE5JG8kUYrSe+vVtvZjLYmIU2qc tDXSOc6B4rIFT5mA3+mSxkEvArmPUq0EcSsZtOkQ+PaeGBKd9tDGwqM7nwTKXh7zX7cFE3Gb+PPyl 2QaDPOqfcfoaKauzTKKSeepgAMeK2E1FeA2XkYH4/wf82fJdKeciBN1T/LY23GDRSPj7n+sNhEmFs h/y7v8HXuEpGkLEmLoA+igJdpbZ41rCVGbFEYHzBsBXsUC5mhXeSY40IhjJoN9zSz39RA43ZU14kf A02P357isXaxY1YSK+d5iw==; 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 1qHrAZ-0004DQ-99; Fri, 07 Jul 2023 15:31:07 -0400 In-Reply-To: <87lefrbvjw.fsf@localhost> (message from Ihor Radchenko on Fri, 07 Jul 2023 15:17:23 +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:307585 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Fri, 07 Jul 2023 15:17:23 +0000 > > Eli Zaretskii writes: > > >> maybe need to have multiple heaps. > > > > All modern implementation of malloc already do use several different > > heaps internally. > > I was talking about Elisp heaps. I don't understand what you mean by "Elisp heaps". Emacs allocates memory by using the system's memory-allocation routines. We don't have our own heaps. > 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. > > There are much more: > > > > 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? > > buffer's base-buffer > > I do not see it. May you point me to where this is changed? See set_buffer_internal_2. How do you investigate this stuff? I type M-. on every macro and function call I see, recursively, and look what they do. If you do the same, how come you overlook all these details? And if you do not use M-., how do you expect to learn what the code does internally? > > 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? How is it useful, in the context of this discussion, to take such a stance? IMO, we should assume that whatever the current code does it does for a reason, and look at the effects of concurrency on the code as it is. > > 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. > > buffer's marker list > > May you point me where it is? In fetch_buffer_markers. Again, I don't understand how you missed that. > > buffer's local variables > > 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. > > Yes, but we have just looked at a single primitive: set-buffer. Once > > in the buffer, any useful Lisp program will do gobs of stuff, and each > > one of those accesses more and more globals. How do you protect all > > that in a 100% reliable way? by identifying the variables and > > structures one by one? what if tomorrow some change in Emacs adds one > > more? > > This sounds like a problem that is already solved by any program that > uses async threads. Maybe Po Lu can provide good insights. Programs that use async threads avoid global variables like the plague. Emacs is full of them. > > Searching for "setq case-fold-search" finds more than 30 hits in Emacs > > alone. And this variable is just an example. > > These are mostly major/minor modes and constructs like > > (setq case-fold-search ...) > (do staff) > (setq case-fold-search old-value) > > The last one is legitimate problem with logic. Although not much > different from Elisp threads doing the same and changing buffer-local > variables in the midst of other thread running in the same buffer. > So, I do not see how this should prevent async threads. We just need to > take care about setq not attempting to write into buffer-local variables > at the same time, which is solved by locking. That "we just need to" is the problem, because it is multiplied by the number of such variables, and they are a lot in Emacs.