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 10:21:08 +0300 Message-ID: <831qhieumz.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <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> <87edljhmjq.fsf@yahoo.com> <87fs5zbuwn.fsf@localhost> <871qhjgrku.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2724"; 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 09:21:57 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 1qI2GT-0000T8-Gx for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 09:21:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI2Ff-0004Lh-2D; Sat, 08 Jul 2023 03:21:07 -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 1qI2Fd-0004LB-Lg for emacs-devel@gnu.org; Sat, 08 Jul 2023 03:21:05 -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 1qI2Fd-0003GR-3e; Sat, 08 Jul 2023 03:21:05 -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=dC5ktp8I8eAke8yNCyZC+K5O6j9yBsErOHJp3PW/3Ac=; b=Z+AxEFM1hOOR Uiw56DhtOmsVgVdlnZnLe8so7AO2IvDck3k2XV2Q7AlHla3aLWSFHsyAwjBJVqdXHkyjL0aYRAA0y o84xHm67AyN0VlzXq1x080JqVqeRjqWo/1R+e99ephaczY7FOjD5grkD8BEQyEMnK3xnYGLwTF0hT 0N2abNtJPSyDTytaX7TXiswysD2UPFTBc8HR9iSJSwJVnq+p2GTz0yU0mDgfLXwvYVmbnRsvU5ps+ +g7iWFtIg7XiAGkMZpb+c5brpN79ZoOto99WFqnbJku9SiX7jAC2dsFWp63qt4A5UmPJ1oUJS6PaC PDopJzY8SsyaZoo5MhwO7Q==; 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 1qI2Fc-0002jy-Ie; Sat, 08 Jul 2023 03:21:04 -0400 In-Reply-To: <871qhjgrku.fsf@yahoo.com> (message from Po Lu on Sat, 08 Jul 2023 08:44:17 +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:307600 Archived-At: > From: Po Lu > Cc: Eli Zaretskii , emacs-devel@gnu.org > Date: Sat, 08 Jul 2023 08:44:17 +0800 > > Ihor Radchenko writes: > > > So, we can hold when interrupt_input_blocked is changed until the thread > > becomes main thread? > > IMHO there should only be a single main thread processing input and > display, since that's required by most GUI toolkits. 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? This is a problem even with the current Lisp threads, and we don't have a satisfactory solution for it. (We discussed this a couple of years back, but didn't arrive at any useful conclusions, AFAIR.) Personally, I don't believe this aspect can be solved without very significant redesign of Emacs and -- what's more important -- without rewriting many Lisp programs to adhere to the new design. Searching for yes-or-no-p and y-or-n-p are in Emacs alone brings 1500 hits. > > Hmm. What about locking thread->current_buffer for all other threads? > > This appears to solve the majority of the discussed problems. > > If you're referring to prohibiting two threads from sharing the same > current_buffer, I doubt that's necessary. > > > I am not sure how to deal with buffer->pt for multiple threads running > > in the same buffer. > > C functions which modify the buffer should be interlocked to prevent > them from running simultaneously with other modifications to the same > buffer. 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 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). IOW, we are no longer talking about some change to Emacs, we are talking about rewriting most or all of Emacs!