bug#8869: Unjustified selection time-out

[Jan Djärv]

19 jun 2011 kl. 21:59 skrev Chong Yidong <cyd@stupidchicken.com>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> 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.
> 
> Ah, thanks for this observation; now I can reproduce the problem, by
> deleting the selection-owning frame using the mouse instead of a
> keystroke.
> 
> The behavior of wait_reading_process_output is indeed problematic, but
> perhaps it's better to work around it in x_get_foreign_selection,
> instead of changing wait_reading_process_output itself.  The following
> patch, for example, changes x_get_foreign_selection to loop calling
> wait_reading_process_output with 1ms intervals.  That allows the
> selection events be handled even if no keyboard input is supplied.
> WDYT?
> 

Maybe it will, but it is a bad solution ( busy wait).  It also does not solve 
the error in process.c. That error may very well be responsible for the hang 
Emacs sometimes does when it should be saving the session and exit.

It is not good to have a potential event handling error in process.c. 


    Jan D.