GNU bug report logs - #50043
28.0.50; USABLE_SIGOI undef code paths do not work correctly

Previous Next

Package: emacs;

Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>

Date: Fri, 13 Aug 2021 11:57:01 UTC

Severity: normal

Found in version 28.0.50

Done: Ken Brown <kbrown <at> cornell.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ken Brown <kbrown <at> cornell.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 50043 <at> debbugs.gnu.org
Subject: bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly
Date: Mon, 15 Nov 2021 10:19:32 -0500
On 8/14/2021 7:52 AM, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>> Do you understand which code un-hangs it when USABLE_SIGIO is defined?
>> Or is it a SIGIO signal that arrives and does that?  If the latter,
>> any idea what causes that SIGIO?
> 
> Nope; haven't digged any further.

I think I found the problem.

x_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type,
			 Lisp_Object time_stamp, Lisp_Object frame)
{
[...]
  wait_reading_process_output (secs, nsecs, 0, false,
			       reading_selection_reply, NULL, 0);

I think wait_reading_process_output gets stuck for 2 seconds in a call to select 
(actually xg_select because I'm testing a gtk build).  This is independent of 
the fact that x-selection-timeout is 2 seconds; it happens even if 
x-selection-timeout is 0.  select returns after 2 seconds because the poll_timer 
fires.  On systems with SIGIO, select returns as soon as X events occur, because 
SIGIO is signaled.

To test my theory, I applied the following patch:

diff --git a/src/process.c b/src/process.c
index f923aff1cb..136873edbb 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5477,9 +5477,10 @@ wait_reading_process_output (intmax_t time_limit, int 
nsecs, int read_kbd,
         triggered by processing X events).  In the latter case, set
         nfds to 1 to avoid breaking the loop.  */
       no_avail = 0;
-      if ((read_kbd || !NILP (wait_for_cell))
-         && detect_input_pending ())
+      if ((read_kbd || !NILP (wait_for_cell)))
+         /* && detect_input_pending ()) */
        {
+         detect_input_pending ();
          nfds = read_kbd ? 0 : 1;
          no_avail = 1;
          FD_ZERO (&Available);

This forces the select call to be skipped, so wait_reading_process_output just 
keeps looping, checking for input, and checking for a cell change.  With this 
patch, the hang is gone.

I'm not suggesting that this patch is the right fix.  But somehow we have to 
improve how polling for input is done on systems without SIGIO, at least in the 
situation above in which we're waiting for a cell.  There's a comment in 
process.c around line 5304 that says "the wait is supposed to be short" in this 
case.

We certainly don't want to always skip the select call, but would it make sense 
to use a very short timeout for select in that case?  Or maybe someone has a 
better idea.

Ken




This bug report was last modified 3 years and 245 days ago.

Previous Next


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