bug#16737: Question about wait_reading_process_output

bug#16737: Question about wait_reading_process_output

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I've been digging into the code trying to get an idea of why
>> bug#16737 fires. My question is where in wait_reading_process_output
>> does it ensure the various terminal socket reads are run?

This doesn't really address your question but maybe it gives an
indication.  Since bug#16737 started occurring to be, I compile emacs
with -DTRACE_SELECTION and then collect the output it delivers.  The
below output was gathered when I yanked into emacs where it always took
5 seconds (`x-selection-timeout') until the text I had previously copied
from the browser was inserted.  This seems to be another instance of the
bug because actually the correct text has been inserted; it just took
very long.

Bye,
Tassilo

--8<---------------cut here---------------start------------->8---
6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7511)
6019: x_stop_queuing_selection_requests 1
6019: x_handle_selection_event
6019: x_handle_selection_event
6019: x_start_queuing_selection_requests 1
6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
6019:  XInternAtom LENGTH
6019:  XInternAtom FILE_NAME
6019:  XInternAtom CHARACTER_POSITION
6019:  XInternAtom LINE_NUMBER
6019:  XInternAtom COLUMN_NUMBER
6019:  XInternAtom OWNER_OS
6019:  XInternAtom HOST_NAME
6019:  XInternAtom USER
6019:  XInternAtom CLASS
6019:  XInternAtom NAME
6019:  XInternAtom SAVE_TARGETS
6019: Sending all 84 bytes
6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7512)
6019: x_stop_queuing_selection_requests 1
6019: x_handle_selection_event
6019: x_handle_selection_event
6019: x_start_queuing_selection_requests 1
6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
6019:  XInternAtom LENGTH
6019:  XInternAtom FILE_NAME
6019:  XInternAtom CHARACTER_POSITION
6019:  XInternAtom LINE_NUMBER
6019:  XInternAtom COLUMN_NUMBER
6019:  XInternAtom OWNER_OS
6019:  XInternAtom HOST_NAME
6019:  XInternAtom USER
6019:  XInternAtom CLASS
6019:  XInternAtom NAME
6019:  XInternAtom SAVE_TARGETS
6019: Sending all 84 bytes
6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7513)
6019: x_stop_queuing_selection_requests 1
6019: x_handle_selection_event
6019: x_start_queuing_selection_requests 1
6019: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
6019:  XInternAtom LENGTH
6019:  XInternAtom FILE_NAME
6019:  XInternAtom CHARACTER_POSITION
6019:  XInternAtom LINE_NUMBER
6019:  XInternAtom COLUMN_NUMBER
6019:  XInternAtom OWNER_OS
6019:  XInternAtom HOST_NAME
6019:  XInternAtom USER
6019:  XInternAtom CLASS
6019:  XInternAtom NAME
6019:  XInternAtom SAVE_TARGETS
6019: Sending all 84 bytes
6019: Sent SelectionNotify: CLIPBOARD, target TARGETS (7514)
6019: x_stop_queuing_selection_requests 1
6019: x_handle_selection_event
6019: x_handle_selection_clear
6019: x_handle_selection_event
6019: x_handle_selection_clear
6019: Get selection UTF8_STRING, type _EMACS_TMP_
6019:   Start waiting 5 secs for SelectionNotify
6019:   Got event = 0
6019: Get selection UTF8_STRING, type _EMACS_TMP_
6019:   Start waiting 5 secs for SelectionNotify
6019:   Got event = 0
6019: Received SelectionNotify
6019: Get selection STRING, type _EMACS_TMP_
6019:   Start waiting 5 secs for SelectionNotify
6019:   Got event = 0
6019: Received SelectionNotify
--8<---------------cut here---------------end--------------->8---

bug#16737: Question about wait_reading_process_output

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 14 Jun 2015 23:47:42 -0400
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > I've been digging into the code trying to get an idea of why bug#16737
> > fires. My question is where in wait_reading_process_output does it
> > ensure the various terminal socket reads are run?
> 
> I see noone replied yet.  I can't really help you because I don't know
> this code at all, but I really hope someone else will come along to
> help,

I will try.

The terminal socket reads are run in gobble_input, which is called
from detect_input_pending (via a few intermediaries).  Emacs calls
detect_input_pending when the pselect call in
wait_reading_process_output finds that some input has arrived, and
wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL
arguments having values that tell it to do so.

Does this answer your question?

bug#16737: Question about wait_reading_process_output

[Alex Bennée]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sun, 14 Jun 2015 23:47:42 -0400
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> > I've been digging into the code trying to get an idea of why bug#16737
>> > fires. My question is where in wait_reading_process_output does it
>> > ensure the various terminal socket reads are run?
>> 
>> I see noone replied yet.  I can't really help you because I don't know
>> this code at all, but I really hope someone else will come along to
>> help,
>
> I will try.
>
> The terminal socket reads are run in gobble_input, which is called
> from detect_input_pending (via a few intermediaries).  Emacs calls
> detect_input_pending when the pselect call in
> wait_reading_process_output finds that some input has arrived, and
> wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL
> arguments having values that tell it to do so.
>
> Does this answer your question?

Sort of. One thing that's confusing is there are two pselect() calls in
the function:

	  if ((pselect (max (max_process_desc, max_input_desc) + 1,
			&Atemp,
#ifdef NON_BLOCKING_CONNECT
			(num_pending_connects > 0 ? &Ctemp : NULL),
#else
			NULL,
#endif
			NULL, &timeout, NULL)
	       <= 0))

and

#if defined (HAVE_NS)
          nfds = ns_select
#elif defined (HAVE_GLIB)
	  nfds = xg_select
#else
	  nfds = pselect
#endif
            (max (max_process_desc, max_input_desc) + 1,
             &Available,
             (check_write ? &Writeok : 0),
             NULL, &timeout, NULL);

Why the two? Could there be a case where one is triggering handling so
that the second never gets evaluated?

Am I right in thinking all incoming X messages (such as those associated
with cut/paste) will come in via the X terminals gobble_input?

-- 
Alex Bennée

bug#16737: Question about wait_reading_process_output

[Alex Bennée]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sun, 14 Jun 2015 23:47:42 -0400
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> > I've been digging into the code trying to get an idea of why bug#16737
>> > fires. My question is where in wait_reading_process_output does it
>> > ensure the various terminal socket reads are run?
>> 
>> I see noone replied yet.  I can't really help you because I don't know
>> this code at all, but I really hope someone else will come along to
>> help,
>
> I will try.
>
> The terminal socket reads are run in gobble_input, which is called
> from detect_input_pending (via a few intermediaries).  Emacs calls
> detect_input_pending when the pselect call in
> wait_reading_process_output finds that some input has arrived, and
> wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL
> arguments having values that tell it to do so.
>
> Does this answer your question?

Sort of. One thing that's confusing is there are two pselect() calls in
the function:

	  if ((pselect (max (max_process_desc, max_input_desc) + 1,
			&Atemp,
#ifdef NON_BLOCKING_CONNECT
			(num_pending_connects > 0 ? &Ctemp : NULL),
#else
			NULL,
#endif
			NULL, &timeout, NULL)
	       <= 0))

and

#if defined (HAVE_NS)
          nfds = ns_select
#elif defined (HAVE_GLIB)
	  nfds = xg_select
#else
	  nfds = pselect
#endif
            (max (max_process_desc, max_input_desc) + 1,
             &Available,
             (check_write ? &Writeok : 0),
             NULL, &timeout, NULL);

Why the two? Could there be a case where one is triggering handling so
that the second never gets evaluated?

Am I right in thinking all incoming X messages (such as those associated
with cut/paste) will come in via the X terminals gobble_input?

-- 
Alex Bennée

bug#16737: Question about wait_reading_process_output

[Eli Zaretskii]

> From: Alex Bennée <alex.bennee@linaro.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 16737@debbugs.gnu.org
> Date: Mon, 15 Jun 2015 17:15:59 +0100
> 
> > The terminal socket reads are run in gobble_input, which is called
> > from detect_input_pending (via a few intermediaries).  Emacs calls
> > detect_input_pending when the pselect call in
> > wait_reading_process_output finds that some input has arrived, and
> > wait_reading_process_output was called with READ_KBD or WAIT_FOR_CELL
> > arguments having values that tell it to do so.
> >
> > Does this answer your question?
> 
> Sort of. One thing that's confusing is there are two pselect() calls in
> the function:
> 
> 	  if ((pselect (max (max_process_desc, max_input_desc) + 1,
> 			&Atemp,
> #ifdef NON_BLOCKING_CONNECT
> 			(num_pending_connects > 0 ? &Ctemp : NULL),
> #else
> 			NULL,
> #endif
> 			NULL, &timeout, NULL)
> 	       <= 0))
> 
> and
> 
> #if defined (HAVE_NS)
>           nfds = ns_select
> #elif defined (HAVE_GLIB)
> 	  nfds = xg_select
> #else
> 	  nfds = pselect
> #endif
>             (max (max_process_desc, max_input_desc) + 1,
>              &Available,
>              (check_write ? &Writeok : 0),
>              NULL, &timeout, NULL);
> 
> Why the two?

They watch different (but not orthogonal) sets of channels.

> Could there be a case where one is triggering handling so
> that the second never gets evaluated?

There's no 'continue;' between the 2 calls to 'pselect', so I don't
see how this could happen.

But it's much easier to put a breakpoint at each call to 'pselect',
which just announces itself and continues, or increments some counter,
than reason about that humongous loop.  Then you'd see very quickly if
the scenario that bothers you can actually happen.

> Am I right in thinking all incoming X messages (such as those associated
> with cut/paste) will come in via the X terminals gobble_input?

I think so, but I don't really know, sorry.