all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.