bug#16737: Question about wait_reading_process_output

[Eli Zaretskii <eliz@gnu.org>]

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