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: Sun, 09 Jul 2023 15:08:44 +0300 Message-ID: <83mt059tir.fsf@gnu.org> 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> <87mt058l1b.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29936"; 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 Sun Jul 09 14:09:29 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 1qITEH-0007bb-9e for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 14:09:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qITDU-00061n-H4; Sun, 09 Jul 2023 08:08:40 -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 1qITDT-00061c-FJ for emacs-devel@gnu.org; Sun, 09 Jul 2023 08:08:39 -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 1qITDS-0002PE-Bs; Sun, 09 Jul 2023 08:08:38 -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=4t8FJJDD8cEuqUtUEx8Va/KZDajewD9pG/LeWRKWVNs=; b=m3w7p2hzaYlX 816x1al14TYpk3PIVhIEM3NRljDZOdvWGW+NqUjMY0V1DmhNTD8vOycni32EnBNIal/2Zyae0ZN6Q ZijY2Lm8HQXcJed0f0WBPrOzx2s9W6WtiePVibIp/y+VjemFk4jw8g6X7fVZKV8JEgr8Yl/Llub9V qRF1+UOSOPf4i2m0PFkQAv8wQVE8wxnIUTn/4reEDmlrZC3RJJvuzhN+F7L2iksoNnhCvU6HMNbQS Loj5j2wL5KDi7yr7Z6/uSs+02P8VA6reSpzO9d9zm7B0hhmWXFkK9oHPyMnOY8UscsVX61teRKxi0 4MNTzPjQoyoU2s+W/tho2g==; 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 1qITDR-00057y-Kg; Sun, 09 Jul 2023 08:08:37 -0400 In-Reply-To: <87mt058l1b.fsf@localhost> (message from Ihor Radchenko on Sun, 09 Jul 2023 09:57:20 +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:307667 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Sun, 09 Jul 2023 09:57:20 +0000 > > 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. Famous last words ;-) > Of course, if there are breaking future changes on C level will need to > account for concurrency. Who will remember that we at some point "assumed" buffer->base_buffer can change _only_ in make-indirect-buffer? > >> > 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? In all other respects, the indirect buffer and its base buffer are completely separate. They have different names, independent values of point, independent narrowing, independent markers and overlays (though inserting or deleting text in either buffer relocates the markers and overlays for both), independent major modes, and independent buffer-local variable bindings. Or did you exclude overlays and their properties from the above? > >> 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. And what happens if that thread also changes Vfoo? > So, redisplay will have access to correct local values. No, it won't, because redisplay runs only in the main thread, remember? So it will not see changes to Vfoo done by other threads. This could sometimes be good (e.g., if the changes are temporary), but sometimes bad (if the changes are permanent). > >> 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. This goes back to the other sub-thread, where we discussed how to show and prompt the user from non-main threads. The conclusion was that there is no good solution to that. The best proposal, wait for the main thread, would mean that stuff like stealth fontifications, which currently run from timers, cannot be run from a thread. > >> 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 see no difference between locking everything and locking just 95%. > 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. Consing is not even the tip of the iceberg. The real bad problems are elsewhere: in the global objects we access and modify.