bug#8869: Unjustified selection time-out

bug#8869: Unjustified selection time-out

[Stefan Monnier]

Package: Emacs
Version: 24.0.50

I recently started to get "selection time out errors" when deleting
frames, which more recently turned into "mere delays", but they're still
present.  Maybe it is true that my system is misconfigured, but AFAIK
I never messed with any clipboard configuration and no other application
seems to exhibit such a delay when exiting, so I suspect there's a bug
in our handling.
E.g. I suspect the new code sometimes thinks there's a "modern clipboard
manager" running when in reality there simply isn't any.  Or maybe your
delay is much longer than what is used by other applications.


        Stefan




In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2011-06-12 on ceviche
Windowing system distributor `The X.Org Foundation', version 11.0.11002000
configured using `configure  'CFLAGS=-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DSYNC_INPUT -DENABLE_CHECKING -DXASSERTS -DFONTSET_DEBUG -g -O1 -I/usr/include/GNUstep' '--enable-maintainer-mode' '--with-x-toolkit=lucid''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_CH.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  diff-auto-refine-mode: t
  gnus-mailing-list-mode: t
  electric-pair-mode: t
  electric-indent-mode: t
  url-handler-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
i t SPC i n t o SPC s o m e t h i n g SPC y o u SPC 
l i k e C-a <up> <return> M-q <backspace> <left> <right> 
<down> <left> <down> <right> <left> <down> <right> 
<left> <right> <up> <up> <left> <right> <down> <left> 
<right> <down> <left> <right> <down> C-SPC <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> C-w <C-down> <C-left> 
<C-right> <C-down> <C-left> <C-right> <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> C-SPC 
<C-down> C-w Y u c k . <M-backspace> H m m . . . SPC 
n o t SPC s u r e SPC w h y SPC i t SPC d o e s n ' 
t SPC u s e SPC w i t h - s e l e c t e d - w i n d 
o w . <return> <up> <up> <up> <up> <left> <right> <down> 
<left> <right> <down> <left> <right> <up> <left> <right> 
<down> <left> <right> <down> <down> <left> <right> 
<right> <return> <return> M-i S t e f a n <up> <up> 
<up> <up> <up> <up> <left> C-a <left> <right> <down> 
<left> <right> <down> <left> <right> <down> <down> 
<left> <right> C-c <down-mouse-1> <mouse-1> <double-down-mouse-1> 
<mouse-movement> <double-mouse-1> <backspace> <backspace> 
C-/ C-/ <up> <up> <left> <backspace> , SPC b u t SPC 
y e s , SPC p r o v i d i n g SPC a SPC ` w i n d o 
w ' SPC a r g u m e n t SPC i s SPC e v e n SPC b e 
t t e r . C-c C-c <switch-frame> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<help-echo> M-x r e p o r t - e m - b u <backspace> 
<backspace> g b <backspace> <backspace> b u <tab> 
<return>

Recent messages:
Mark set [2 times]
Auto-saving...done
call-interactively: End of buffer
Undo! [2 times]
Sending...
Sending via mail...
Sending...done
X clipboard manager error: Timed out waiting for reply from selection owner
If the problem persists, set `x-select-enable-clipboard-manager' to nil.
Warning: interactive-p is obsolete!

Load-path shadows:
None found.

Features:
(shadow emacsbug woman tutorial help-macro man info-look info help-at-pt
ehelp apropos cus-edit cus-start cus-load nndoc url-http url-gw url-auth
rect dabbrev gnus-dup vc-bzr filecache bbdb-com bbdb timezone debug
multi-isearch nnfolder canlock gnus-html browse-url xml url-cache mm-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-util diff-mode jka-compr gnus-fun supercite regi executable
copyright pp mule-util flow-fill sort smiley ansi-color gnus-cite
mail-extr gnus-async gnus-bcklg qp gnus-ml nndraft nnmh rfc2104
network-stream starttls nnimap parse-time tls utf7 netrc nnagent nnml
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 epg-config mm-view mml-smime smime dig mailcap nntp
gnus-cache nnir gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
server gnus-start gnus-spec gnus-int gnus-range message sendmail
format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems nnheader mail-utils wid-edit noutline outline
easy-mmode flyspell ispell eldoc checkdoc regexp-opt thingatpt help-mode
easymenu view prog-mode electric url-handlers url-parse auth-source
warnings eieio byte-opt bytecomp byte-compile cconv macroexp assoc
gnus-util time-date password-cache url-vars mm-util mail-prsvr reveal
autoinsert uniquify advice help-fns advice-preload savehist
minibuf-eldef disp-table cl cl-loaddefs proof-site proof-autoloads
pg-vars bbdb-autoloads agda2 tooltip ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register
page newcomment menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting x-toolkit x multi-tty emacs)

bug#8869: Unjustified selection time-out

[David De La Harpe Golden]

> E.g. I suspect the new code sometimes thinks there's a "modern clipboard
> manager" running when in reality there simply isn't any.

What does

(x-selection-exists-p 'CLIPBOARD_MANAGER)

return on your system?

> Or maybe your
> delay is much longer than what is used by other applications.

Emacs uses 20s delay by default (x-selection-timeout), qt/kde and 
gtk/gnome apps are about 10s (estimated by watching them on my system, 
didn't dig the exact timeout figure from their sources)

So emacs is waiting twice as long as other apps, but at 10s, I'd still 
expect the delay in most other apps to be fairly noticeable (for the 
apps that try to persist at exit at all).  Mind you, some other apps' 
visible/inputoutput windows do disappear at the start rather than end of 
their wait, though, which might be perceptually hiding the issue.  For 
Qt/KDE apps, watch out for the stderr message  "QClipboard: Unable to 
receive an event from the clipboard manager in a reasonable time" 10 
secs after "closing" them.

There's also something of an architectural question raised (though might 
be a bit late to do anything about it given looming pretest, it's not a 
showstopper): You're seeing the delay when deleting frames - but there 
might be ways around emacs asking for its clipboard to be saved in such 
cases a lot of the time:

Right now a given emacs frame['s x11 window] is used as the selection 
owner, AFAIUI.  When that frame is to be deleted, emacs asks the 
clipboard manager (if one is detected) to save.  But if it's not the 
last frame opened via a given terminal/display connection, that is a 
little wasteful.

Emacs doesn't currently keep an extra per-terminal invisible/input-only 
window lurking (or maybe it does and I just don't know about it) - in 
contrast AFAICS gtk+ opens a per-process per-display GtkInvisible for 
owning selections [1][2][3], and Qt probably does something vaguely 
similar.  Emacs could in principle do similar.*

Or if we don't want to do something like that,  then I suppose the 
ownership could be "migrated" to another visible frame on that terminal 
rather than doing that, "just" set selection owner to another living 
frame, though that could cause some history-keeping clipboard managers 
to have duplicate entries (though ones I've used do do dupe checking).

[1] http://developer.gnome.org/gtk/2.24/GtkInvisible.html
[2] http://git.gnome.org/browse/gtk+/tree/gtk/gtkclipboard.c#n451
[3] http://git.gnome.org/browse/gtk+/tree/gtk/gtkinvisible.c#n239


* Well, gtk+ toolkit builds of emacs may wind up with gtk+'s dangling 
unused and ignored, emacs doesn't use gtk+'s clipboard handling.

bug#8869: Unjustified selection time-out

[Jan D.]

David De La Harpe Golden skrev 2011-06-16 03:00:

> Right now a given emacs frame['s x11 window] is used as the selection
> owner, AFAIUI. When that frame is to be deleted, emacs asks the
> clipboard manager (if one is detected) to save. But if it's not the last
> frame opened via a given terminal/display connection, that is a little
> wasteful.
>
> Emacs doesn't currently keep an extra per-terminal invisible/input-only
> window lurking (or maybe it does and I just don't know about it) - in
> contrast AFAICS gtk+ opens a per-process per-display GtkInvisible for
> owning selections [1][2][3], and Qt probably does something vaguely
> similar. Emacs could in principle do similar.*

There is the session-leader window.  Not designed for this, but could do 
the job.  On the other hand, creating a new selection-holding window is 
not much job.  For multidisplay you actually need one window per 
display, so the session leader isn't really appropriate.  That is 
display as in X11 Display*, not display as in multiscreen.

	Jan D.

bug#8869: Unjustified selection time-out

[Stefan Monnier]

> What does
> (x-selection-exists-p 'CLIPBOARD_MANAGER)
> return on your system?

It returns t.

>> Or maybe your delay is much longer than what is used by
>> other applications.
> Emacs uses 20s delay by default (x-selection-timeout), qt/kde and gtk/gnome
> apps are about 10s (estimated by watching them on my system, didn't dig the
> exact timeout figure from their sources)

I don't actually know which application other than Emacs implements this
protocol, but gnome-terminal exits in less than 1s, same for Firefox
(well, it might take a bit more than 1s for Firefox, but it's still
pretty close).


        Stefan

bug#8869: Unjustified selection time-out

[David De La Harpe Golden]

On 16/06/11 14:44, Stefan Monnier wrote:
>> What does
>> (x-selection-exists-p 'CLIPBOARD_MANAGER)
>> return on your system?
>
> It returns t.
>

So, well, it does sound like you do have something that looks like a 
clipboard manager hanging about  ...but what? (i.e. what process is the 
owner of that selection...).  Of course, if other apps aren't being 
affected, maybe it is an issue with emacs rather than the clipboard 
maanger.  But to investigate further, it would still be good to know 
what version of what clipboard manager you're running (even if you 
didn't know you were running one...).

ISTR you once mentioning you used a fairly old-school desktop setup, 
don't know what you're using now - given you mention gnome-terminal, 
though, can you see if you have the "gnome-settings-daemon" process 
hanging around? It's a clipboard manager among other things.

I'm a bit slow to blame the new code, as we've already seen one buggy 
clipboard manager (a particular version of xfce4-settings-helper, now 
superseded).  We did also have one user report a problem under their 
gnome desktop, but neither Chong Yidong nor myself could replicate it 
(#8779).

> I don't actually know which application other than Emacs implements this
> protocol, but gnome-terminal exits in less than 1s, same for Firefox
> (well, it might take a bit more than 1s for Firefox, but it's still
> pretty close).
>

gnome-terminal was one of the apps I tested with, it takes 10 secs to 
timeout on my system if I make my clipboard manager malfunction in such 
a way that it still claims to exist but doesn't work (and of course have 
just copied in gnome-terminal). Testing firefox (or actually iceweasel) 
it takes a bit over 10 secs too.

Uh. Can you start from a fresh emacs -Q and reliably replicate the 
issue, or is it only happening sometimes even considering only those 
times you've just copied in emacs?

bug#8869: Unjustified selection time-out

[Stefan Monnier]

> ISTR you once mentioning you used a fairly old-school desktop setup, don't
> know what you're using now - given you mention gnome-terminal, though, can

Here's the idea:
- standard Debian testing Gnome setup.
- killall metacity.
- start good'ol ctwm, emacs, and xterm.
- add a zest of xmodmap+xresources.

I never use gnome-terminal because good'ol xterm works just fine, thank you.

> you see if you have the "gnome-settings-daemon" process hanging around?

Yes, it's there.  `dpkg' tells me it's package version 2.30.2-3.

> gnome-terminal was one of the apps I tested with, it takes 10 secs to

So, my random pick of gnome-terminal for testing was a good one, great.

> Uh. Can you start from a fresh emacs -Q and reliably replicate the issue, or
> is it only happening sometimes even considering only those times you've just
> copied in Emacs?

Hmm... I'm indeed having some trouble replicating the problem from
"emacs -Q".  I rarely if ever delete frames or exit Emacs, so I didn't
notice it, but it seems to only appear when I send an email/news message
with Gnus (these are placed in dedicated frames).
OK, I'll try and come up with a self-contained test case.  Thanks,


        Stefan

bug#8869: Unjustified selection time-out

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On 17/06/11 03:56, Stefan Monnier wrote:
>> ISTR you once mentioning you used a fairly old-school desktop setup, don't
>> know what you're using now - given you mention gnome-terminal, though, can
>
> Here's the idea:
> - 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. You might be regarding that as a feature. However, 
if you're using the usual gdm display manager and you want a "pure ctwm" 
session with no gnome, which might also be useful to see if the problem 
still happens under it (probably won't, given no clipboard manager), an 
alternative might be to drop the attached file into

/usr/share/xsessions/ctwm.desktop

at least until such a time as the ctwm debian package supplies its own 
session definition (there's been a bug about the missing definition open 
since 2005, sigh: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330045 ), then you 
should just be able to select CTWM at login time.

(The openbox wm package bundles more complex session definitions, 
including ones showing how to "cleanly" do openbox+gnome or openbox+kde)

[-- Attachment #2: ctwm.desktop --]
[-- Type: application/x-desktop, Size: 114 bytes --]

bug#8869: Unjustified selection time-out

[Chong Yidong]

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.

bug#8869: Unjustified selection time-out

[Jan Djärv]

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.
>
>

bug#8869: Unjustified selection time-out

[Jan Djärv]

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.
>>
>>
>
>

bug#8869: Unjustified selection time-out

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 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.

I stared at the code a long time, and I think it should have no bad
effect.  I've committed a slightly tweaked version of this fix; let's
see how it plays out.  Thanks for debugging.

bug#8869: Unjustified selection time-out

[Jan Djärv]

Hi.

I was not sure how the interaction between read_kbd being 0 and different 
types of events (keyboard, mouse vs the rest) are supposed to work.
But if you are sure then that is good.  Anyway we have a long time to release 
yet :-)

BTW, should the bug be closed?

	Jan D.


Chong Yidong skrev 2011-06-26 05.40:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> 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.
>
> I stared at the code a long time, and I think it should have no bad
> effect.  I've committed a slightly tweaked version of this fix; let's
> see how it plays out.  Thanks for debugging.

bug#8869: Unjustified selection time-out

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I was not sure how the interaction between read_kbd being 0 and
> different types of events (keyboard, mouse vs the rest) are supposed
> to work.  But if you are sure then that is good.  Anyway we have a
> long time to release yet :-)

I am as sure as anyone can be from staring at that particular piece of
code.  So let's see ;-)

> BTW, should the bug be closed?

Yeah; closing.

bug#8869: Unjustified selection time-out

[Stefan Monnier]

>> I was not sure how the interaction between read_kbd being 0 and
>> different types of events (keyboard, mouse vs the rest) are supposed
>> to work.  But if you are sure then that is good.  Anyway we have a
>> long time to release yet :-)
> I am as sure as anyone can be from staring at that particular piece of
> code.  So let's see ;-)
>> BTW, should the bug be closed?
> Yeah; closing.

FWIW, I still see the same problem.


        Stefan

bug#8869: Unjustified selection time-out

[Jan Djärv]

2011-07-01 03:32, Stefan Monnier skrev:
>>> I was not sure how the interaction between read_kbd being 0 and
>>> different types of events (keyboard, mouse vs the rest) are supposed
>>> to work.  But if you are sure then that is good.  Anyway we have a
>>> long time to release yet :-)
>> I am as sure as anyone can be from staring at that particular piece of
>> code.  So let's see ;-)
>>> BTW, should the bug be closed?
>> Yeah; closing.
>
> FWIW, I still see the same problem.
>

What window system are you using?
Does the frame close if you press the close button (assuming you have one) and 
then move the mouse a bit?

Can you now reliably reproduce it with emacs -Q or is it still after gnus usage?

	Jan D.

bug#8869: Unjustified selection time-out

[Stefan Monnier]

> Can you now reliably reproduce it with emacs -Q or is it still after
> gnus usage?

it only ever happens when I send a message from Gnus (which I do from
a dedicated frame).  In that same session, deleting frames (which own
the clipboard) in general works just fine.  It's only when that frame is
deleted as part of the C-c C-c that sends the message that the problem
shows up.


        Stefan

bug#8869: Unjustified selection time-out

[Stefan Monnier]

> What window system are you using?

ctwm.

> Does the frame close if you press the close button (assuming you have one)
> and then move the mouse a bit?

Aha!  Thanks, now I have a recipe for one of those problems:

emacs -Q
C-x 5 2
C-SPC M-< M-w
press the close button (yes, I do have it, tho it's not a button, it's
just one of the many operations available in one of the menus ;-).

then Emacs will first wait 20s and then delete the frame (with the
clipboard-timeout message in the remaining frame).


        Stefan

bug#8869: Unjustified selection time-out

[David De La Harpe Golden]

On 06/07/11 14:29, Stefan Monnier wrote:
>> What window system are you using?
>
> ctwm.
>

Still in the run-gnome-kill-metacity-run-ctwm way?

bug#8869: Unjustified selection time-out

[Stefan Monnier]

>>> What window system are you using?
>> ctwm.
> Still in the run-gnome-kill-metacity-run-ctwm way?

Yes.  I logged in, tested with metacity (confirmed that the problem
doesn't show up in that case), then killed metacity and started ctwm,
after which I tested again.


        Stefan

bug#8869: Unjustified selection time-out

[David De La Harpe Golden]

On 08/07/11 03:20, Stefan Monnier wrote:
>>>> What window system are you using?
>>> ctwm.
>> Still in the run-gnome-kill-metacity-run-ctwm way?
>
> Yes.  I logged in, tested with metacity (confirmed that the problem
> doesn't show up in that case), then killed metacity and started ctwm,
> after which I tested again.
>

With a fresh emacs process or the same one?

bug#8869: Unjustified selection time-out

[Stefan Monnier]

>>>>> What window system are you using?
>>>> ctwm.
>>> Still in the run-gnome-kill-metacity-run-ctwm way?
>> Yes.  I logged in, tested with metacity (confirmed that the problem
>> doesn't show up in that case), then killed metacity and started ctwm,
>> after which I tested again.
> With a fresh emacs process or the same one?

With a fresh Emacs process each time.


        Stefan

bug#8869: Unjustified selection time-out

[Glenn Morris]

Stefan Monnier wrote:

> Aha!  Thanks, now I have a recipe for one of those problems:
>
> emacs -Q
> C-x 5 2
> C-SPC M-< M-w
> press the close button (yes, I do have it, tho it's not a button, it's
> just one of the many operations available in one of the menus ;-).
>
> then Emacs will first wait 20s and then delete the frame (with the
> clipboard-timeout message in the remaining frame).


Similar problems using current trunk on RHEL6.2 under XFCE 4.8:

emacs -Q
C-SPC M-< M-w
C-x C-c

Emacs sits there for 20 seconds before exiting, then prints

  Error saving to X clipboard manager.
  If the problem persists, set `x-select-enable-clipboard-manager' to nil.

in the terminal.

I've never seen another application pause in this way before exiting.

This keeps bugging me when I use `emacs -Q' to test things.

I can't even set x-selection-timeout to something small via
X resources, because -Q ignores those. :(

bug#8869: Unjustified selection time-out

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Similar problems using current trunk on RHEL6.2 under XFCE 4.8:
>
> emacs -Q
> C-SPC M-< M-w
> C-x C-c

Hmm, I couldn't reproduce this, also on XFCE 4.8.  But I did see the
timeout problem when clicking on the "close window" button rather than
doing C-x C-c.  There, the problem is that when Emacs is waiting for the
selection request from the clipboard manager, swallow_events doesn't get
to handle the selection request event because there's a
DELETE_WINDOW_EVENT sitting in the keyboard buffer in front of it.

I committed a changed to make process_special_events deal with all X
selection events in the keyboard fifo buffer.  Does that happen to fix
things for you?

bug#8869: Unjustified selection time-out

[Glenn Morris]

Chong Yidong wrote:

> I committed a changed to make process_special_events deal with all X
> selection events in the keyboard fifo buffer.  Does that happen to fix
> things for you?

Sorry, no. Some general comments:

1) 20 seconds seems a very long default. If whatever Emacs wants to
contact does not respond in say 5 seconds, is it likely to in 20?

2) Someone who starts Emacs from a menu item as opposed to a terminal
probably won't see the message about x-select-enable-clipboard-manager.
Could you not print "Attempting to contact clipboard manager..."
in Emacs before it starts doing whatever it does?

3) I had no idea whether I am running a clipboard manager or not.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8760
says xfce4-settings-helper may be responsible. I do have version
4.8.0 < 4.8.2. So probably this is a duplicate of that report. Oops.
Sorry for the noise. I'll write a PROBLEMS entry.

If I could figure out how to disable the xfce4 clipboard manager,
I could tell for sure...

4) The CLIPBOARD_MANAGER arg of x-selection-exists-p isn't documented.

bug#8869: Unjustified selection time-out

[Glenn Morris]

Glenn Morris wrote:

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8760
> says xfce4-settings-helper may be responsible. I do have version
> 4.8.0 < 4.8.2. So probably this is a duplicate of that report. Oops.
> Sorry for the noise. I'll write a PROBLEMS entry.

Upgraded to xfce4-settings-helper 4.8.3 and the issue went away.
I think my other points stand though.

bug#8869: Unjustified selection time-out

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> 1) 20 seconds seems a very long default. If whatever Emacs wants to
> contact does not respond in say 5 seconds, is it likely to in 20?
>
> 2) Someone who starts Emacs from a menu item as opposed to a terminal
> probably won't see the message about x-select-enable-clipboard-manager.
> Could you not print "Attempting to contact clipboard manager..."
> in Emacs before it starts doing whatever it does?
>
> 4) The CLIPBOARD_MANAGER arg of x-selection-exists-p isn't documented.

I've fixed these in trunk.  Thanks.

bug#8869: Unjustified selection time-out

[Chong Yidong]

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?


*** src/xselect.c       2011-06-06 19:43:39 +0000
--- src/xselect.c       2011-06-19 19:49:23 +0000
***************
*** 1207,1213 ****
    Atom type_atom = (CONSP (target_type)
             ? symbol_to_x_atom (dpyinfo, XCAR (target_type))
                   : symbol_to_x_atom (dpyinfo, target_type));
-   int secs, usecs;
  
    if (!FRAME_LIVE_P (f))
      return Qnil;
--- 1207,1212 ----
***************
*** 1243,1253 ****
    UNBLOCK_INPUT;
  
    /* This allows quits.  Also, don't wait forever.  */
-   secs = x_selection_timeout / 1000;
-   usecs = (x_selection_timeout % 1000) * 1000;
    TRACE1 ("  Start waiting %d secs for SelectionNotify", secs);
!   wait_reading_process_output (secs, usecs, 0, 0,
!                                             reading_selection_reply,
NULL, 0);
    TRACE1 ("  Got event = %d", !NILP (XCAR (reading_selection_reply)));
  
    if (NILP (XCAR (reading_selection_reply)))
--- 1242,1258 ----
    UNBLOCK_INPUT;
  
    /* This allows quits.  Also, don't wait forever.  */
    TRACE1 ("  Start waiting %d secs for SelectionNotify", secs);
!   {
!     int j, periods = max (1, x_selection_timeout);
!     for (j = 0; j < periods; j++)
!       {
!       wait_reading_process_output (0, 1000, 0, 0,
!
    reading_selection_reply, NULL, 0);
!   if (!NILP (XCAR (reading_selection_reply)))
!     break;
!       }
!   }
    TRACE1 ("  Got event = %d", !NILP (XCAR (reading_selection_reply)));
  
    if (NILP (XCAR (reading_selection_reply)))

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. 

bug#8869: Unjustified selection time-out

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 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.

Hmm, I'm not sure I understand what you're saying.  My impression is
that Emacs is getting stuck on wait_reading_process_output's select()
call, which doesn't exit to do the necessary X event processing until
some user input is available.  If that's the case, then the problem is
calling select() with a long timeout.

bug#8869: Unjustified selection time-out

[Jan Djärv]

Chong Yidong skrev 2011-06-19 23.13:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> 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.
>
> Hmm, I'm not sure I understand what you're saying.  My impression is
> that Emacs is getting stuck on wait_reading_process_output's select()
> call, which doesn't exit to do the necessary X event processing until
> some user input is available.  If that's the case, then the problem is
> calling select() with a long timeout.

I disagree.  The problem is not calling select with a ong timeout, the problem 
is not checking if there is queued events and handling them before entering 
select.

Checking Emacs as I run it, select is usually enetered with a timeout betweeen 
10 and 15 seconds, so the potential for this happening is great.

Any solution to a problem that increases frequency of polling is just 
fundamentally wrong.  It leads to increased CPU usage, and since code is 
executed often, it can not be swapped out. Also, debugging such code is hard 
because breakpoints can't be used reliably since the code depends on busy wait 
or polling.  Please do not commit that patch.

	Jan D.

bug#8869: Unjustified selection time-out

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> The problem is not calling select with a ong timeout, the problem is
> not checking if there is queued events and handling them before
> entering select.
>
> Checking Emacs as I run it, select is usually enetered with a timeout
> betweeen 10 and 15 seconds, so the potential for this happening is
> great.

But the selection request from the other X client can arrive at any
time, not necessarily before we enter the select.  If the front part of
wait_reading_process_output executes very quickly, we'll enter the
select before a response is ready, in which case Emacs will wait the
entire 20 seconds if no other input is available.

Other than reducing the select timeout, what solution is there?

bug#8869: Unjustified selection time-out

[Jan Djärv]

Chong Yidong skrev 2011-06-20 16.57:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> The problem is not calling select with a ong timeout, the problem is
>> not checking if there is queued events and handling them before
>> entering select.
>>
>> Checking Emacs as I run it, select is usually enetered with a timeout
>> betweeen 10 and 15 seconds, so the potential for this happening is
>> great.
>
> But the selection request from the other X client can arrive at any
> time,

No, it can't.  It must arrive after SAVE_TARGET and it is not read unless any 
X code (XNextEvent or gtk_events_pending()) is executed.

> not necessarily before we enter the select.

> If the front part of
> wait_reading_process_output executes very quickly, we'll enter the
> select before a response is ready, in which case Emacs will wait the
> entire 20 seconds if no other input is available.

No, in that case the X request has not been read and it still in the socket.
Select will then detect that and return.  It is not before XTread_socket is 
called the event is actually read.

	Jan D.