From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Sun, 09 Jul 2023 15:14:36 +0800 Message-ID: <87o7kleeub.fsf@yahoo.com> References: <871qhnr4ty.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> <83h6qed8kw.fsf@gnu.org> <87h6qefwj0.fsf@yahoo.com> <83bkgmcx0q.fsf@gnu.org> <87a5w5gbs4.fsf@yahoo.com> <83bkglbmai.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="20292"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: yantar92@posteo.net, 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 09:15:44 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 1qIOe0-00055V-HW for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 09:15:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIOdB-0002L8-J2; Sun, 09 Jul 2023 03:14:53 -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 1qIOd9-0002Ke-EP for emacs-devel@gnu.org; Sun, 09 Jul 2023 03:14:51 -0400 Original-Received: from sonic314-22.consmr.mail.ne1.yahoo.com ([66.163.189.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qIOd7-0005PK-GC for emacs-devel@gnu.org; Sun, 09 Jul 2023 03:14:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688886886; bh=UJMxGIKv93pmBRdwAiQr0UG21j/PIcwSR7Lna62sXIY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=oqayTKF3pnMKTGItO9g0CH0oAzqtYDQShM643s0a/R2Il321nEOSRgvjCJo0BYnW+sL8UT970oMQTlmIgDUa47/IcFO77gP5UI2xhCeiq3rp58AgdKvgiHykilcGXFFilJaWhHDWUd+UoKq+msV/NRnXQ+XyNvY3d8ayiwYNqwgojmwcI5oisrSIXDJV04jkNPF3xzNo4YeJbrVYFbSqQw+FFCx2B/R94yY8uLTfuPDz5LCN4m3qbpUih90KmJACXRaRNqyXcYrXK5yXYKGlY6ETU8b2fdNuf0ag5pLnLjK6GwQ+OtbpRjD0qy+ckfvly3iY/n+dMTWV+zgx/SmUYQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688886886; bh=fsscC3Unxo0/BIbqAEPuNFqw4nAg5R6hLB0tIQ/ZaZj=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Zy3yZ3ZxXIFfNSTb4VWHP+C2KckpCm9WirkdmDsgLwRJd4X4I8Yz+s0icLqVFOr6kmSfaSkleD9cD02asXSWaE1qJ4thwKuVdPL9S3k6G7VxVLAkw5iWL9EcnmXMkJFjECs6fZ34zMEJeITRJ3ywF2wIdiAERhGi9FHw6waPk698ZFuKnEV8yXEdzNUMkjfiZPezLAoirBy4x6djesOWRhjfGG0o02ZrAyBbrv7fnm+S3y3idFldTlDoKHNdEGX1CMbZcsOpc2aKcldWycE1cTyi4tYx0i3iOXytoihoqro5/Jg65+UBJTPZbWkiQfXRs/y/IpS5dfpHDUOFz/NuFw== X-YMail-OSG: uu3QoFUVM1n28qJRiks_dv0fBSspFRf7rwERzD8Z5srgCh.Duyx6BG13tMNHE6u i.wbN9ZOeWR7rwSCfX.rqwBd7iJvfBAHXZI2zoKLvTjdTMNeHFTXYESI4QRcbzhhUPxOqfm9US31 aLfTpPoYv2una85WaEqwEEngai_mY3.fwoQgmJVTD5L3z.SPwFNwf49I.r4h5o_66rdmT0q6AM8H bFNTdpzf_ViXtTZGdrqDfH6zPw2UWJKd2m5aBe2NUaId0yuv50t9PY..lSSGfV1lNButrNtQhfWU TavcP2bIuu5IuToKgux9Hq3kkdW7ZnSCJSn.GA5L9PhqWyh.EnJQ0d6bJPw4XDnEprrP.EJLmnzo OPcdYvZZaSF5M3sh.nsJx9l7ZzJ10dUc4NDhNrcn1mYr1zMVI89RkptHwkwxLxr9TLbfXGfhijQy 8JY_IAg6xdtk1lObQc8oj7kJoSDB2BtQKNTHNqqK2KKDuAcwn.Qpue_oXSwfSZvCWBdXo03WFuy3 5MpyIe9UhRcVzK5Y7yncpYC4Q8dHLqOe42kzMRU6ch1OzU..QlTR9Uo.nXoxvaPGcAXHwyFS92H7 ThK7dxp0OdKqD3hR6oH5tNM6lEE1SrW8GaMDElc.J.ckMoKp8RgVL7mv7WDnxLBQnnynUizVORBw 9q5cyvpMd3s8X_Bv_adH.7BUrIS2QARFxPygT8hfiStfyTn6EV7tW9MuK1N2HT2CY8B0cKwAls_L YmvxPEmg17xFAAKvrakb1QOYh1fwqDBW8qbtLqFsEGilXB349iSOKV4vKdlLJ0cukvHg2dQMnT05 w2IBxkDlThZX8XDYs7AJDEysE9JFWn6pMtseYDHlRq X-Sonic-MF: X-Sonic-ID: b76d30f0-a34c-4908-8c5d-1d288e334eaa Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sun, 9 Jul 2023 07:14:46 +0000 Original-Received: by hermes--production-sg3-67fd64777-lqw65 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 52d6c4169ed63b280b44fd3ac9aff17c; Sun, 09 Jul 2023 07:14:41 +0000 (UTC) In-Reply-To: <83bkglbmai.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Jul 2023 10:01:57 +0300") X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.189.148; envelope-from=luangruo@yahoo.com; helo=sonic314-22.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:307643 Archived-At: Eli Zaretskii writes: > That is of course not always possible, or even desirable. For > example, some prompts are caused by specific aspects of the > processing, which may or may not happen, depending on the data. > Prompting for options unrelated to the actual processing would mean > annoying users unnecessarily. Etc. etc. In that case, the thread will have to suspend itself until the main thread can read a response from the user. > So basically, what you have in mind is a way of accruing a body of > special-purpose Lisp programs written specifically for running from > non-main threads. Which means reusing existing code or packages not > written to these specifications will be impossible, and we will in > effect have two completely separate flavors of Emacs Lisp programs. > It would mean, in particular, that many functions in simple.el, > subr.el, and other similar infrastructure packages will need to have > specialized variants suitable for running in non-main threads. Yes. > And all this will be possible if -- and it's a large "if" -- the > necessary support on the C level will be written and prove reliable. > > If this is the plan, it might be possible, at least in principle, but > is it really what is on people's mind when they dream about "more > concurrent Emacs"? I doubt that. I don't know what other people think, but it's what I would find desirable, as my gripe with tools like Semantic is that they cannot run expensive text crunching tasks in the background. Having shared-memory multiprocessing would allow these tasks to be implemented efficiently. > Memory is cheap these days, and "slow IO" is still a gain when it > allows us to use more than a single CPU execution unit at the same > time. So yes, efficiency is desirable, but ease of use is also > important. What's more, I don't think anyone really wants to have to > write Lisp programs in a completely different way when we want them to > run from threads. When programmers write such code for other interactive programs, they are comfortable with the limitations of running code outside of the UI thread. Why should writing new, thread-safe Lisp for Emacs be any more difficult? > Those mechanisms only work when Emacs is idle, which is bad for > features like progress reporting. Doing this right requires to > redesign how redisplay kicks in, and probably have several different > kinds of redisplay, not one. Maybe. I haven't worked out the details of that yet, but in most other GUI programs and toolkits, messages from other threads can only be processed by the UI thread while it is idle. > I think none of them are side-effect free, if you look closely. They > access buffer text, they move point, they temporarily change the > selected window and the current buffer, the access and many times > modify the obarray, etc. etc. `intern' should be interlocked so that only one thread is accessing the obarray at any given time. Point and buffer text shouldn't prove a problem, provided that the buffer being used is not accessed from any other thread. But yes, many of these functions will have to be audited and possibly rewritten for multi-threaded correctness.