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

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 63865 <at> debbugs.gnu.org
Subject: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes
Date: Sat, 03 Jun 2023 08:30:57 -0400

Po Lu <luangruo <at> yahoo.com> writes:

> Spencer Baugh <sbaugh <at> janestreet.com> writes:
>
>> Po Lu <luangruo <at> yahoo.com> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>>>>> Date: Fri, 02 Jun 2023 21:55:09 -0400
>>>>> 
>>>>> 
>>>>> 1. Under X11, with the GTK or Lucid toolkits:
>>>>>    emacs -Q
>>>>> 2. Become owner of the clipboard selection by killing some text; the
>>>>>    starting comments in the scratch buffer are a good candidate.
>>>>> 3. Immediately afterwards (i.e. without copy and pasting text in another
>>>>>    window), run:
>>>>>    (call-process "sleep" nil nil nil "inf")
>>>>> 4. Now other applications will hang when they attempt to paste text.
>>>>>    Google Chrome and Slack are two examples.  (GTK-based applications
>>>>>    seem to be fine.  So much for proprietary software...)
>>>>
>>>> Thanks.
>>>>
>>>> Does this happen also with the latest pretest, v29.0.91?
>>>
>>> I can't reproduce this, but the closest thing to Google Chrome on the
>>> computer I am currently using is Firefox 10.0.7.
>>
>> BTW, this can also be reproduced using just Emacs.  If I try to paste in
>> another Emacs instead of in Google Chrome, I get a hang, followed by:
>>
>> gui-get-selection: (error "Timed out waiting for reply from selection owner")
>
> Emacs doesn't hang...

Well, it hangs for 10 seconds, then times out, because Emacs is
correctly implemented.  Some other applications are incorrectly
implemented and never time out.

>> With -DTRACE_SELECTION on both Emacsen, the selection-owner Emacs prints
>> no logs, while the pasting Emacs prints the following log:
>>
>> 48866: Get selection UTF8_STRING, type _EMACS_TMP_
>> 48866:   Start waiting 5 secs for SelectionNotify.
>> 48866:     Waiting for 0 nsecs in addition.
>> 48866:   Got event = NO
>> 48866: Get selection TIMESTAMP, type _EMACS_TMP_
>> 48866:   Start waiting 5 secs for SelectionNotify.
>> 48866:     Waiting for 0 nsecs in addition.
>> 48866:   Got event = NO
>>
>>> So would you also build Emacs with -DTRACE_SELECTION, and show what is
>>> printed by Emacs when the requestor hangs?
>>
>> Emacs prints nothing while stuck in call-process and the requestor
>> (Chrome) is hanging.
>
> OK, but then this is not a bug: Emacs can not respond to selection
> requests when it is not reading keyboard input.

"Emacs can not respond to selection requests when it is not reading
keyboard input." sounds like a bug to me!  Even if it's hard to fix,
it's still a bug.

If I'm implementing some package and I decide to use call-process for
some long operation, then some user uses my package and it runs
call-process, and they get bored while waiting and switch away from
Emacs, they'll experience a hang in some other application.  That hang
seems clearly undesirable!

(I should mention that Slack (and possibly all Electron applications)
have worse behavior than I originally said: They don't just hang on
paste, their UI hangs completely while Emacs is in call-process.  (I
guess these applications are constantly requesting the selection or
something?)  Which is an extremely bad experience for the users of
packages which use call-process...)

I'm personally working around this by replacing call-process with
start-process and accept-process-output.  Because otherwise my packages
(and any other package using call-process ever) will cause random hangs
in other applications, which is obviously bad and not something anyone
would want.

So perhaps call-process on Unix should be reimplemented in terms of
those functions?  Or if that would change behavior too much, perhaps
call-process should be deprecated in favor of some new helper built on
those?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.