bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly


From: Ken Brown
Subject: bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly
Date: Mon, 15 Nov 2021 10:19:32 -0500
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0

On 8/14/2021 7:52 AM, Lars Ingebrigtsen wrote:
Eli Zaretskii <eliz@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]