bug#8869: Unjustified selection time-out

["Jan Djärv" <jan.h.d@swipnet.se>]

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<david@harpegolden.net> 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.
>>
>>
>
>