bug#63865: 29.0.90; call-process while owning the X selection hangs other processes

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: luangruo@yahoo.com,  63865@debbugs.gnu.org
>> Date: Sat, 03 Jun 2023 10:12:41 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> 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?