From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes Date: Sat, 03 Jun 2023 10:41:15 -0400 Message-ID: References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> <83a5xg8vzo.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="22433"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 03 16:42:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1q5SSV-0005ga-Ph for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 03 Jun 2023 16:42:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q5SSC-00021u-L0; Sat, 03 Jun 2023 10:42:04 -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 1q5SSB-00021f-2J for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 10:42:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q5SSA-0008OK-QI for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 10:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q5SSA-0007Xy-87 for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 10:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2023 14:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63865 X-GNU-PR-Package: emacs Original-Received: via spool by 63865-submit@debbugs.gnu.org id=B63865.168580328528955 (code B ref 63865); Sat, 03 Jun 2023 14:42:02 +0000 Original-Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 14:41:25 +0000 Original-Received: from localhost ([127.0.0.1]:44108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SRY-0007Ww-Ri for submit@debbugs.gnu.org; Sat, 03 Jun 2023 10:41:25 -0400 Original-Received: from mxout6.mail.janestreet.com ([64.215.233.21]:34541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SRV-0007Wd-3B for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 10:41:23 -0400 In-Reply-To: <83a5xg8vzo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 17:24:11 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262858 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org >> Date: Sat, 03 Jun 2023 10:12:41 -0400 >> >> Eli Zaretskii writes: >> >> > Really? "tons of places where it will run for prolonged periods of >> > time"? what is "prolonged period of time" for this purpose? Aren't >> > you a tad exaggerating? >> >> "prolonged period of time" is anything over a second. >> >> I see tons of calls to call-process with potentially long-running >> programs. "find", "gcc", "grep", "awk"... and depending on the user's >> system, *any* subprocess call can potentially run for a long time. > > Please be specific. For example, "grep" runs in an async subprocess; > we run it with call-process when we probe it for support of some > command-line option. If you can show that these calls take "prolonged > period of time", please describe what you do and show the timing. No, I mean "grep" called specifically by call-process. As, for example, I see happening in mh-grep-execute-search and nnspool-find-id. In the former case, it's a recursive grep which could take many seconds. Or as I already mentioned: xref-matches-in-files (used by project-find-regexp, C-x p g) uses call-process-region to run recursive grep in an arbitrary directory. Which could easily take minutes. These are understandable designs, and I'm not too bothered by the fact that they block Emacs. But this becomes much worse when they are also blocking other applications because of this X selection bug. >> But again, the point isn't just that they can potentially run for a long >> time. It's that *the user's whole system can be unusable* while they >> run. We are not just blocking Emacs, we are (sometimes) blocking >> *everything*. > > AFAIU, the only "everything" that is blocked is an application that > happens to request an X selection at that precise time. That should > be rare for short enough call-process runs, since the same user is > doing that. No, as I mentioned earlier, some (buggy, of course) applications frequently request the X selection; such as Slack (and possibly all other Electron applications too). Such applications just immediately hang during the entire call-process run without any user interaction. In my case, Google Chrome and Slack are the only non-Emacs applications I use. So... for me, everything gets blocked. >> (defun my-call-process (program &optional destination &rest args) >> (let ((process (make-process :name "call-process" >> :buffer destination >> :command (cons program args)))) >> (while (accept-process-output process)))) >> >> my-call-process is missing a few arguments that the real call-process >> has. But if this is all I use, is there *any* reason to *not* use >> my-call-process on Linux? > > You are free to do it if it suits your needs. Emacs provides those > primitives to you. > > But saying that this should replace call-process in each and every > case is a non-starter. > >> There is at least one strong reason to use it: It won't hang other >> processes. > > Yes, and gazillion complications, like handling the SIGCHLD signal, > pselect interface, etc. > >> > Anyway, this kind of discussion doesn't belong in a bug report about X >> > selections. >> >> But the entire point of this discussion, for me, is to fix the >> X-selection-related hangs which Emacs currently causes when in >> call-process. i.e., this bug report. > > It doesn't matter, because you insist on making the issue much more > general. I would be happy with a targeted, specific fix for the bad behavior I reported. Here's a specific instance that would be good to fix: If I run "M-! sleep 30 RET", that will cause some applications to hang while Emacs is waiting on the sleep; sometimes (as with Slack) without user interaction, or sometimes only if the user tries to paste in them. Do you have a suggestion on how to fix that?