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 13:02:55 +0300 Message-ID: <83h6qed8kw.fsf@gnu.org> References: <871qhnr4ty.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> <87edljhmjq.fsf@yahoo.com> <87fs5zbuwn.fsf@localhost> <871qhjgrku.fsf@yahoo.com> <831qhieumz.fsf@gnu.org> <87lefqg7yl.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7962"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 08 12:03:32 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 1qI4mo-0001mz-Am for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 12:03:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI4mG-0002Fy-4V; Sat, 08 Jul 2023 06:02:56 -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 1qI4mF-0002Fp-5N for emacs-devel@gnu.org; Sat, 08 Jul 2023 06:02:55 -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 1qI4mE-0000Qh-T8; Sat, 08 Jul 2023 06:02:54 -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=YgtimyouXI9o2o+43ecWczLYDSwDq/xxGBB7UKrIPpg=; b=HUi+LNNQ1vzt QzC1JTSNRx7Sk3PwCBCloMRRX7yd/2H2AVreVbdIWwQy2ZA+rqRLzvLDPOMk6c+SXOh0mAwE0qC1g hs4jYI7hQrpf6C+1RhClE6POm7dDJILXRaAyO3BzQKuRbz6iQi2ROlNsvRlI0sCBt90FhmevSJkNX cdA/Ij3m9gazPex2pQQBf4IpmWfHkcQt0vyvXUIrPqbolTwu37N2MNq8nDJLgERQxMoBvcsjtCjR6 MexMa5Q1RjQ2GkKLvqYir9+V4d88wqNZGWp9b7GI2f2upIK4eIF8wzoDgXC9/oUBT3oRDgmuqKPCX C5FLVYS99bDVwFPrhi1V/Q==; 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 1qI4mD-0005Ci-8I; Sat, 08 Jul 2023 06:02:53 -0400 In-Reply-To: <87lefqg7yl.fsf@yahoo.com> (message from Po Lu on Sat, 08 Jul 2023 15:48:02 +0800) 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:307608 Archived-At: > From: Po Lu > Cc: yantar92@posteo.net, emacs-devel@gnu.org > Date: Sat, 08 Jul 2023 15:48:02 +0800 > > Eli Zaretskii writes: > > > That is already a problem, as long as we are talking about leaving > > most of Emacs application code intact. How do you ensure only the > > main thread can process input and display? A non-main thread can > > easily call some function which prompts the user, e.g., with > > yes-or-no-p, or force redisplay with sit-for, and what do you do when > > that happens? > > To signal an error. Great! that means in practice no existing Lisp program could ever run in a non-main thread. It isn't a very practical solution. Besides, non-main threads do sometimes legitimately need to prompt the user. It is not a programmer's error when they do. > Threads other than the main thread should not call > such functions, which is the approach taken by most toolkits and window > systems. (X being a notable exception, where every Xlib display is > surrounded by one massive lock.) I don't think such a simplistic solution suits a program such as Emacs. > This will mean that most user facing Lisp won't be able to run in > parallel with the main thread, but that can be fixed, given enough time. Fixed how? > > That's not enough! Interlocking will prevent disastrous changes to > > the buffer object which risk leaving the buffer in inconsistent state, > > but it cannot prevent one thread from changing point under the feet of > > another thread. Consider this sequence: > > > > . thread A moves point to position P1 > > . thread A yields > > . thread B moves point of the same buffer to position P2 > > . thread B yields > > . thread A resumes and performs some processing assuming point is at P1 > > Lisp code that is interested in making edits this way will need to > utilize synchronization mechanisms of their own, yes. The above doesn't do any editing, it just accesses buffer text without changing it. > > Without some kind of critical section, invoked on the Lisp level, > > whereby moving point and the subsequent processing cannot be > > interrupted, how will asynchronous processing by several threads that > > use the same buffer ever work? And please note that the above is > > problematic even if none of the threads change buffer text, i.e. they > > all are just _reading_ buffer text. > > > > It follows that such asynchronous processing will have to be > > explicitly accounted for on the level of Lisp programs, which means > > thorough rewrite of most of Lisp code (and also a lot of C code). > > Insofar as that Lisp code is actually interested in making use of > multiple threads. Why are we talking about multiple threads at all? don't we want to allow some Lisp code run from non-main threads? > > IOW, we are no longer talking about some change to Emacs, we are > > talking about rewriting most or all of Emacs! > > I think that as long as we make the C text editing primitives robust > against such problems, authors of Lisp code that needs to edit buffer > text from multiple threads will devise appropriate synchronization > procedures for their specific use cases. For example, to parse a buffer > in the background, Semantic may chose to create a new thread with a > temporary copy of the buffer that is being read. Or, Gnus might do the > same to fontify a Diff attachment in an article. Lisp changes can all > be accomplished gradually, of course, whereas the C-level changes will > have to be completed all in one go. Using a snapshot of some global resource, such as buffer text, works only up to a point, and basically prohibits many potentially interesting uses of threads. That's because such snapshotting assumes no significant changes happen in the original objects while processing the snapshot, and that is only sometimes true.