bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8869: Unjustified selection time-out


From: Jan Djärv
Subject: bug#8869: Unjustified selection time-out
Date: Sun, 19 Jun 2011 13:14:40 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.18) Gecko/20110613 Thunderbird/3.1.11

Hi.

Some more debugging.

At the top of the while loop in wait_reading_process_output, there is this:

      if (read_kbd >= 0)
        QUIT;
#ifdef SYNC_INPUT
      else
        process_pending_signals ();
#endif

This is the code that reads the SelectionRequest and queues it.
But from here on, there is no code that checks if input is pending, so the function gets stuck in select a bit down.

There is a check before select:

      if (read_kbd && detect_input_pending ())
        {
          nfds = 0;
          no_avail = 1;
        }

This fails for two reasons.  In this situation, read_kbd is zero.
Also, setting nfds to zero makes the selection code think it timed out.

Adding this patch:

=== modified file 'src/process.c'
--- src/process.c       2011-06-14 18:57:19 +0000
+++ src/process.c       2011-06-19 11:09:30 +0000
@@ -4484,6 +4484,11 @@
          nfds = 0;
          no_avail = 1;
        }
+      else if (read_kbd == 0 && detect_input_pending ())
+       {
+         nfds = 1;
+         no_avail = 1;
+       }
       else
        {

fixes the timeout issue in this report, but probably has some bad effect elsewhere.

        Jan D.




Jan Djärv skrev 2011-06-19 12.26:
Hi.

There is something wrong with the implementation for SAVE_TARGETS.
What happens is:

1) Emacs sends SAVE_TARGET and starts to wait for SelectionNotify.
2) The clipboard manager tries to get the CLIPBOARD selection with a
SelectionRequest.
3) Emacs receives this but does not reply to it, as it is only intereted in
SelectionNotify.
4) If an input event, such as mouse move, occurs, the loop is broken and all
queued X Events are handeled, including SelectionRequest.
5) The clipboard manager has gotten the clipboard from Emacs and only now
sends SelectionNotify.

Thus, if there isn't any input in 4), the exit will time out.
Emacs must handle SelectionRequest in 3) to work correctly.

Jan D.


Chong Yidong skrev 2011-06-19 00.03:
David De La Harpe Golden<address@hidden> writes:

- standard Debian testing Gnome setup.
- killall metacity.
- start good'ol ctwm, emacs, and xterm.

Well, if you're literally doing that, that will tend to leave bits of
gnome hanging about.

Yeah, though that doesn't explain why "no other application seems to
exhibit such a delay when exiting". Plenty of other applications ought
to be supporting the clipboard manager spec these days.

There are various possible workarounds, e.g. we could have
x_clipboard_manager_save_frame set x-select-enable-clipboard-manager to
nil if it hits a timeout, so that the delay at least won't recur in the
same session. But it wouldn't be wise to implement them until we get a
few more details about the actual failure case.









reply via email to

[Prev in Thread] Current Thread [Next in Thread]