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 08:37:47 +0800 Message-ID: <87a5w5gbs4.fsf@yahoo.com> References: <871qhnr4ty.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> <83h6qed8kw.fsf@gnu.org> <87h6qefwj0.fsf@yahoo.com> <83bkgmcx0q.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="37675"; 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 02:39:01 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 1qIIS4-0009Z2-U9 for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 02:39:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIIR5-0007og-PQ; Sat, 08 Jul 2023 20:37:59 -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 1qIIR4-0007oY-QE for emacs-devel@gnu.org; Sat, 08 Jul 2023 20:37:58 -0400 Original-Received: from sonic314-21.consmr.mail.ne1.yahoo.com ([66.163.189.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qIIR3-0008VG-2z for emacs-devel@gnu.org; Sat, 08 Jul 2023 20:37:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688863074; bh=gRaVL5jPWOJoSEwQLy91aC7OIpJskxzBg895wwB/KUM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=qXuZlQGK6jideIk8E4S8GOaevHF/gYNal6LOcIdykOUTobHhhtQkA+1WXTouwbx9ki7IX/B3Q5rvo5kfydieabofndTSnF/NiEyoBCTnzjZ+9MKWY7gKqnp747+hqagTSCuC3KvvTxP1yMjoE2cuOZ11MMdvCkIJz+SNvorM5guR1ooewZPCKnW93AlqjJs80Gbg3cYs4CVXRaHhhy9xrQtPWUBJ3h19r9qyQH6lx48F5yQJWrMhNcz6GNcRpYmanicOwJIw8wjNPkX/W2sk4LIYCNRIkXT0lzu+rKb5X8vFEnezYkpjmGZdft2jgZgjJLqWCf/ppyjeAHESXgmFCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688863074; bh=QjKHfd/JDCga9vmN8rEgRGXGb9+42QP85PR3mra7nNl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=TdwJ/PAfE9FDIHv+BugjPpIJrFuzV/KVRknIs3umlO4lhVmrBZvFsJmtYVcGhKtIeMCuKDaHbSpbqfDAdOCgLDUEhW0QgNkhuUZgIcmI+9JFCFfF8vd6UgAu50cVy4Zg2PSqC/eWMTaG4O1RSwk8cAb/980yJS9L+2gPmR4MNMqLl9arPYODl0gtd0zLW/eXAo/lQWGcRWkz49VeJiI362CMAdHac2dubhWKMKFyuS5j/hJMx9ujR9UhKUkzLFab34hIzYK7AVn1A3ojCZOCymUywXDRY5KrvHkmvXLr686z9u+CS3TSI1L8bi2AEnmzbpqenhgW89U33WyH3ZPGDw== X-YMail-OSG: QjZU7twVM1la5nOaYsKG1M7ZN00kkUqgDHxBKlfGt.j5dWan.t4VFB_nMakxQcw EPb8QLrKZbTEcV5f5LVUe4B2xcxt8QVdvUwTfvDqzf6rLOGJnsCqyBRQzHb18JC1Ho_vMzkgSUWw NIh3NUfUy4lQhpq_jqc0hl9EvtaXAZNQ21OjlcxEVHkVEHKNqiALzEy4f074gwwaz2xRB5UH48Bl MOQeZyg_BcxAic4rtAk_qlG3PEpoug_5eiUxDJLFO9fTSdioEBNx0Jh.NDkd0GnLuvKZ0wdGWTr2 1DD0Nb3tmRU9t.OxkspVj.Bbe_4rC.MjmsD4mFkTeXiVBOBF1z5PP0FNjs2_m5fwUztellDpJ354 oNRTMexXSFYvElqQ2Xc6D1Xuy_LWxOSLaJOX8wLKpiYTr41THk026UxF_Hg.7o.xDafg1zqIT9Q6 xAvI15TsDEpICJSJ9pL6.Kezk_CfFa7CgvsagA7fuIlgBiITzxiqHdnrjWXMHGkklgNik6f4YA1F hAnUKyS4LQIWDNUYri.4GoWMliMUlfyoyr8GBpWd8Dfy7VP.jobj3rapmgySxMNhJm958K0zI2U1 lP5TggLQnHAQSTym6OYR11IThf8oB7dKpi1TTwMvuugzpJHtK0uOS_UfKAGVbCpzWdvlrBF8Vrkg xlK66twt.4284KpwsMaCquyQx24z3wm8wW8LPSkCUK88B7afuCL.o.dKPeIa1hvH5Cuj57z7LIFl XTRv0nIdi_PXyaga6n7QAheCceQ_N3rTQbYYhSL70ewzIDLqqEnWId..DnBTToewjlVvWt_PvSHQ .kdL32XfGdY1ADvZpPLMC1DzUiue19q_CW9AQ12.4M X-Sonic-MF: X-Sonic-ID: de490340-16d8-464d-817a-2eea91e0acc6 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sun, 9 Jul 2023 00:37:54 +0000 Original-Received: by hermes--production-sg3-67fd64777-vq8mf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 94e90ba51d42ae58a82d019bfe4e3901; Sun, 09 Jul 2023 00:37:52 +0000 (UTC) In-Reply-To: <83bkgmcx0q.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Jul 2023 17:12:37 +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.147; envelope-from=luangruo@yahoo.com; helo=sonic314-21.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:307633 Archived-At: Eli Zaretskii writes: > Are they allowed to, say, write some data to a file? If so, they > might need to ask the user whether its okay to overwrite an existing > file. They might chose to use `write-region' instead, or save the file from the main thread. > IOW, I think you have a very narrow idea of "number and text crunching > tasks" that could benefit from threads. For example, one of the > frequent requests is to run the part of Gnus that fetches email and > articles in a separate thread -- if this is okay for "number and text > crunching tasks", then it is likely to prompt users. Prompting for options should take place before the thread is started, or after the data is retrieved and about to be displayed. > We are mis-communicating. My point is that it is almost impossible to > take an existing non-trivial Lisp program and let it run from a > non-main thread without bumping into this issue. Your responses > indicate that you agree with me: such Lisp programs need to be written > from scratch under the assumption that they will run from a non-main > thread. I agree with this completely. From my POV, such requirements are reasonable and not very different from the requirements for doing so in other GUI toolkits and programs. > How is this compatible with the goal of having threads in Emacs, which > are to allow running Lisp code with less hair than the existing timers > or emacs-async? I thought the concern was one of efficiency, and not ease of use: process IO is slow compared to sharing the same VM space, and subprocesses also utilize more memory. >> > Fixed how? >> >> By replacing `sit-for' with `sleep-for' (and in general avoiding >> functions that call redisplay or GUI functions.) > > So programs running in non-main threads will be unable to do stuff > like show progress etc.? That's not very encouraging, to say the > least. They should be able to run code from the main thread's command loop, via mechanisms such as `unread-command-events'. > This basically means rewriting most of Emacs. Because most APIs and > subroutines we use in every Lisp program were not "specifically > written for running outside the main thread". So we'll need special > variants of all of those to do those simple jobs. I wasn't thinking about Lisp functions used for text editing tasks, but rather raw data crunching functions. Most of these are already side-effect free, and some are even truly reentrant.