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:12:37 +0300 Message-ID: <83bkgmcx0q.fsf@gnu.org> References: <871qhnr4ty.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> <83h6qed8kw.fsf@gnu.org> <87h6qefwj0.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13011"; 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 16:13:36 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 1qI8gp-0003C8-KV for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 16:13:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI8fr-0007BL-LY; Sat, 08 Jul 2023 10:12:35 -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 1qI8fq-0007B7-1n for emacs-devel@gnu.org; Sat, 08 Jul 2023 10:12:34 -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 1qI8fp-0005ui-Ov; Sat, 08 Jul 2023 10:12:33 -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=pPkTl3pUEzwaoBYCRvtFP5YqpUO833RUJctSxnF1BWw=; b=V9YAuf6+cokw 97hm/DML7Ne9+fjRxOK/JDtGuJtsC2iLRK445YZZ6Nm6GkogAfVmznFDMNs3zo0sHOx0L5UZNVySd ht8opEToTlg+ySGYKLsjolwPR3xl6ZuZbYBAg4FkO/XNitu4EcSgcZ4KI1r0e07DjGfWp0D0CdNwH LujnDvad0JKr1GmkBHJFZeBQe2wHjpT1BeoNu6r4R+RoCOlT1yXNHv21Y6n+f5Ne2Fbx+0P2nyxsb QGm8rC4+7xafNH0RtoHw4Of96ps15huxYLXCOVU6FHXpZxNSKv907MzbXb/WaDJYcyTspR2zIoreb ufq5sZ5C9welOvgbIFL0gA==; 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 1qI8fo-0003ef-FM; Sat, 08 Jul 2023 10:12:33 -0400 In-Reply-To: <87h6qefwj0.fsf@yahoo.com> (message from Po Lu on Sat, 08 Jul 2023 19:54:59 +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:307614 Archived-At: > From: Po Lu > Cc: yantar92@posteo.net, emacs-devel@gnu.org > Date: Sat, 08 Jul 2023 19:54:59 +0800 > > Eli Zaretskii writes: > > > Great! that means in practice no existing Lisp program could ever run > > in a non-main thread. It isn't a very practical solution. > > Number and text crunching tasks (think Semantic, or JSON parsing for > LSP) don't need to sleep or read keyboard input. 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. 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. > > Besides, non-main threads do sometimes legitimately need to prompt > > the user. It is not a programmer's error when they do. > > They should then devise mechanisms for communicating with the main > thread. 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. 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? > > 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. > That code will have to be specifically written for running outside the > main thread, of course, obviating the need to rewrite all of our > existing code. QED 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. > > 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. > > We could also allow Lisp to lock a buffer by hand. Same problem here.