From: Ken Brown <kbrown@cornell.edu>
To: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>
Cc: 50043@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 [thread overview]
Message-ID: <c9a06259-a2cf-2aa6-9b62-f15b4247bcaf@cornell.edu> (raw)
In-Reply-To: <87fsvcuttw.fsf@gnus.org>
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
next prev parent reply other threads:[~2021-11-15 15:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 11:56 bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly Lars Ingebrigtsen
2021-08-13 13:16 ` Eli Zaretskii
2021-08-13 14:31 ` Lars Ingebrigtsen
2021-08-13 15:51 ` Eli Zaretskii
2021-08-14 11:52 ` Lars Ingebrigtsen
2021-11-15 15:19 ` Ken Brown [this message]
2021-11-15 17:24 ` Eli Zaretskii
2021-11-15 19:26 ` Ken Brown
2021-11-16 17:44 ` Eli Zaretskii
2021-11-16 23:06 ` Ken Brown
2021-11-17 7:41 ` Lars Ingebrigtsen
2021-11-17 14:25 ` Ken Brown
2021-11-17 13:14 ` Eli Zaretskii
2021-11-17 14:19 ` Ken Brown
2021-11-17 14:34 ` Eli Zaretskii
2021-11-17 14:59 ` Ken Brown
2021-11-17 16:56 ` Eli Zaretskii
2021-11-17 17:25 ` Ken Brown
2021-11-17 17:37 ` Eli Zaretskii
2021-11-17 17:45 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9a06259-a2cf-2aa6-9b62-f15b4247bcaf@cornell.edu \
--to=kbrown@cornell.edu \
--cc=50043@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.