GNU bug report logs - #16737
24.3.50; Yank causes hang

Previous Next

Package: emacs;

Reported by: Sujith Manoharan <sujith <at> msujith.org>

Date: Thu, 13 Feb 2014 03:49:02 UTC

Severity: important

Tags: moreinfo, patch

Merged with 17026, 17101, 17172, 19320, 20283

Found in versions 24.3.50, 24.4, 25.0.50

Done: Tassilo Horn <tsdh <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Bennée <alex.bennee <at> linaro.org>
Cc: 16737 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#16737: Question about wait_reading_process_output
Date: Mon, 15 Jun 2015 21:04:44 +0300
> From: Alex Bennée <alex.bennee <at> linaro.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16737 <at> 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.




This bug report was last modified 9 years and 244 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.