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: Fri, 07 Jul 2023 20:01:24 +0000 Message-ID: <875y6vbiej.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27093"; 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 Fri Jul 07 22:02:38 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 1qHrf3-0006qR-GF for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jul 2023 22:02:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHre7-00066b-Qc; Fri, 07 Jul 2023 16:01:39 -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 1qHre0-00066L-4J for emacs-devel@gnu.org; Fri, 07 Jul 2023 16:01:38 -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 1qHrdx-0000cA-96 for emacs-devel@gnu.org; Fri, 07 Jul 2023 16:01:31 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 332DD240029 for ; Fri, 7 Jul 2023 22:01:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688760087; bh=96g7y8MhJulvi8+QYgHDXW0U/5qdoYZ38Wz8adqFQA0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=pPAS0JzaiILNS3uS1835q+2+QstYKLyODdqZHHkL/5xj68QORpHSKcE9Y6q9Pe4g9 C2XAhQBdztu8ctJ4fNmXfW80z1KbiwBnmC81plW/nUYnE08hFw+UQ2BJGAX+Ay5oox Qtbt6cAtf0z6SMoNcQ9YTqkP+TBqxJvXBjfwmo0FbHeDwcW1uwByzRlL9me5QZqSYv uBVxalngwh1QQaeyrIrDCBxR3eV9Z7FLUX+eVoyTLfGfNfGubJH8pZwirKsO2NyFgC +atmzSbja3MyTNw/wP4JtPvUKWjoo7aqOhH1K+wu3wEwPbG4MkiZ56JVv2jxXQNKal bsIrQEx7/m4zQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QyPRV4L1Sz9rxB; Fri, 7 Jul 2023 22:01:26 +0200 (CEST) In-Reply-To: <83h6qfecxt.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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:307587 Archived-At: Eli Zaretskii writes: >> 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. Does it mean that we can safely call, for example, Fcons asynchronously? (I am saying the above because my understanding is limited, hoping that you can give some pointers when I happen to be wrong.) >> > 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. It is not always sufficient, of course. When the code expects the value to be unchanged, the lock will take much longer, and may cause global locking eventually. >> > 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? Yes, I use M-. and C-x p g. And I do follow the code. But it does not mean that I fully understand it, sorry. And I still fail to see where base-buffer is _changed_. Is base buffer ever supposed to be changed? >> > 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. >> 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. >> > 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)? >> > 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. >> 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. Fair. I still hope that Po Lu can comment on this. (Do note that my original proposal is not about "true" async thread and it is Po Lu who were pushing for "proper interlocking". But the current discussion is still helpful either way.). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at