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: Sun, 09 Jul 2023 09:57:20 +0000 Message-ID: <87mt058l1b.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <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> <834jmeew2u.fsf@gnu.org> <87a5w6aa89.fsf@localhost> <838rbqcvlx.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="9749"; 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 Sun Jul 09 11:57:51 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 1qIRAt-0002ME-0J for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 11:57:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIRAP-0003ta-2e; Sun, 09 Jul 2023 05:57:21 -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 1qIRAN-0003pg-0t for emacs-devel@gnu.org; Sun, 09 Jul 2023 05:57:19 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIRAK-0004tI-OC for emacs-devel@gnu.org; Sun, 09 Jul 2023 05:57:18 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9CA09240103 for ; Sun, 9 Jul 2023 11:57:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688896634; bh=Yn6zgrnajfqnOzW8VVWCSQq7y4Xmy28xsPQqYWJqRsM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Q9XwzsMvVVCeoT8OfQKI5ith88V4zUZEwelUqJr63RbQ4zWgfs4/0GDCxngKYKyfD qZSYaKV1MO5QtPkvhbVoJhvxAFii3wQPCbgCTarmTZyQHaE8++STUL5/QAaeg0VNzu gBNCImqZDvgxPaJJaTFZvb/7OA//kQxPkkq3vzAT8ZnNP3bFFchxhc95Vs4V/PgcJe 39b2hCQPzfOWKK1AVr2gRDL6WS+HvKdgX8ddB4icW3dLwz+37YloLnfP9WTVWS3on1 4/h6KNfaKTzJEMTjFKWlVUu8uWG9XFrEk8aGDR5LMZjjwoP/uTiATFUMbT2DU84nbL SHmmjM8xPg2wg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QzMxP6w96z6txy; Sun, 9 Jul 2023 11:57:13 +0200 (CEST) In-Reply-To: <838rbqcvlx.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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:307655 Archived-At: Eli Zaretskii writes: >> I was able to identify a single place in C code where buffer's base >> buffer is being set: in make-indirect-buffer, when the buffer is just >> created. So, it is safe to assume that buffer->base_buffer remain >> constant for any given live buffer. Unless I miss something. > > C code can change. It is not carved in stone. Are we going to treat > the current state of the code as if it can never change? That's > unwise. Drastic changes as big as breaking the concept that indirect buffer has a single fixed parent are not likely. Of course, if there are breaking future changes on C level will need to account for concurrency. >> > 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? >> >> Are you sure? Text properties are certainly shared between indirect buffers. > > That's not what the documentation says. May you please point me to this documentation? >> I now looked a bit further, and what you are talking about are the >> variables defined via DEFVAR_PER_BUFFER. > > Non necessarily. Example: show-trailing-whitespace. It has XSYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED; and the loop in set_buffer_internal_2 has if (sym->u.s.redirect == SYMBOL_LOCALIZED >> If my understanding is correct, it should be safe to convert them into >> thread-local variables and update them within current thread when >> current_buffer (already thread-local) is altered. > > It is only safe if no other thread will access the same buffer. For > example, redisplay will be unable to show that buffer if it is visible > in some window, because its notion of the buffer-local values might be > inaccurate. Another thread will have its own local set of Vfoo. When that thread switches to a buffer, it will update its local Vfoo values. So, redisplay will have access to correct local values. >> Will it make sense to convert PT, ZV, and BEGV into thread-local variables? > > What do you expect redisplay to do when some thread moves point in a > way that it is no longer in the window? Async threads will not trigger redisplay. And they will have their own PT, BEGV, and ZV. Basically, I propose async threads not to set buffer->pt in the buffer object. They will operate using their own local excursion and restriction. >> > Buffer's marker list are referenced in subroutines of >> > record_buffer_markers. >> >> Do you mean record_buffer_markers->set_marker_both->attach_marker-> >> if (m->buffer != b) >> { >> unchain_marker (m); >> m->buffer = b; >> m->next = BUF_MARKERS (b); >> BUF_MARKERS (b) = m; >> } >> >> But will this `if' ever trigger for PT, BEGV, and ZV? > > I don't know! You cannot possibly have code where you need to reason > about every single line whether something can or cannot happen there. > You need a relatively small set of basic assumptions that _always_ > hold. Anything more complex makes the task of developing and > maintaining this code an impossible job. Fair. Then, we can block if we need to store thread markers. >> Also, it looks reasonable to block BUF_MARKERS when we need to change >> BUF_MARKERS. > > Sure. Like I said: we'd need to lock everything. I kindly do not agree. It is not like a global lock. Yes, there will be a lot of blocking of individual Elisp objects. But it does not mean that everything will be locked. I think there is a good way to tentatively check if everything will be locked or not - just check what will happen with consing. Consing appears to be one of the biggest bottlenecks that will basically cause global lock. If it can be demonstrated that consing is manageable, other things will pose less of an issue. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at