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: A UI approach for making synchronous commands asynchronous Date: Tue, 01 Aug 2023 20:11:25 +0300 Message-ID: <83bkfq1yde.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25295"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 01 19:12:09 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 1qQsum-0006NP-LM for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Aug 2023 19:12:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQsu1-0007ym-VD; Tue, 01 Aug 2023 13:11:21 -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 1qQsu1-0007yV-4Z for emacs-devel@gnu.org; Tue, 01 Aug 2023 13:11:21 -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 1qQsu0-00069l-NK; Tue, 01 Aug 2023 13:11:20 -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=3HQhzkMMjnzwvzLc85ngxQ/bLenTrfCQiVrYy8YSP1A=; b=b0ZoKYddT0ME /w89PWjVmKBoLBmzrLcYlkUtk9cpji/et1Cp8eKsIcmEN3c1Cn5PP+Ae3FMQUdJYi0rLkCzZRhev2 0xmGxt6kBZ8ODBqyGNldpguhpWP6WJwjcj8p+0YNvIiDLJCHTOJiVPfSB0i8WW1K/IdJ3byeqHdOT vUOCCumiSyMi/iHakswdanTqwIm3fHN2mei6aW96tJEIruWux7XdkOfcKP6zW9Y7Ixh+xhbAPBAD/ PP1yjH+XD2VWmsBMOf1qtFQa7NLCTlcDL/B00xk7d5PlEcCYCbf3gm8vMBi+F5GT2m/SmXMg/Mxqo q87TuPot/m2CK4mZhgoyOA==; 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 1qQsu0-0002K0-5o; Tue, 01 Aug 2023 13:11:20 -0400 In-Reply-To: (message from Helmut Eller on Tue, 01 Aug 2023 18:53:12 +0200) 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:308238 Archived-At: > From: Helmut Eller > Cc: emacs-devel@gnu.org > Date: Tue, 01 Aug 2023 18:53:12 +0200 > > I was wondering what would happen if Emacs would adopt a > one-thread-per-command strategy, i.e. every command starts out in a new > background thread. Based on past discussions, some of the problems with this are: . how to handle user interaction from such "background" commands (e.g., many commands ask the user for confirmation or prompt the user for input of some other kind, like file names) . how to trigger redisplay (and remember that some features, like messages in echo-area, are actually calls to redisplay in disguise) . how to handle timers started by some thread . how to handle output from subprocesses (a subprocess is by default locked to the thread which started it, but interesting stuff happens if that thread exits or dies) But we definitely need to try to use threads more than we do, because if not, we will never acquire solutions to these problems.