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 17:43:06 +0300 Message-ID: <838rbqcvlx.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <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> <834jmeew2u.fsf@gnu.org> <87a5w6aa89.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36830"; 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 16:43: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 1qI9A7-0009MP-BU for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 16:43:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI99N-0003hX-MU; Sat, 08 Jul 2023 10:43:05 -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 1qI99L-0003hB-UB for emacs-devel@gnu.org; Sat, 08 Jul 2023 10:43:04 -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 1qI99K-0004oz-K6; Sat, 08 Jul 2023 10:43:02 -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=V18YoCLg3EXLXQL1KL1ZFmclf9dbguZMCiiGep7niRo=; b=sbA+eaUY53MQ TNtH49e4kRKCEOlILbIxJOkWxlxGZWmwxvv9mewoKPBqhYCGCTnyKhs3i/hhjQ3KYIniJFcLLbmQB WGNZVzpfqmrTob+wMRJzf9I+2F/CDrGlRSenCea0x8b1nTA9Pu4TNueEOyWp9CE2lz6Kn2gK5cBvn tVq7Gsra4XKEnB6yslHfRLcNMCyRnkkVMHPp1hVA2lKR+YoOHSg9j7qkvPJ59wpaikNKNk+abvLlc hJOnfvnK2/ETMcIMJNc4BoE8GQv+Y99UAls5/JFNM+WQM6lLv+mluYFQCESns/RC2kXdRmd+AiDFE Fj1DWSwwfMGkTRpfbaBjLw==; 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 1qI99K-0006TT-2C; Sat, 08 Jul 2023 10:43:02 -0400 In-Reply-To: <87a5w6aa89.fsf@localhost> (message from Ihor Radchenko on Sat, 08 Jul 2023 11:55:34 +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:307616 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Sat, 08 Jul 2023 11:55:34 +0000 > > >> 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. > > 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. > > 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. > >> > 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. > > 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. > 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. > >> > 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. > > It is exactly what happens with current cooperative threads, AFAIK. With the existing threads, this will never happen, because a thread will never yield between moving point to some position and accessing buffer text at that position. > 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? > >> 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. > > 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. > 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.