[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
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly,
Ken Brown <=
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/15
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/15
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Eli Zaretskii, 2021/11/17
- bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly, Ken Brown, 2021/11/17