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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: larsi <at> gnus.org, 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 19:24:02 +0200

> Date: Mon, 15 Nov 2021 10:19:32 -0500
> Cc: 50043 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> 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.

Sorry, I don't understand: select waits for up to 2 seconds because
that's what we ask it to do, and those 2 sec do come from
x-selection-timeout.  If x-selection-timeout is zero, select is not
supposed to wait at all, so why does it?  What am I missing?

> On systems with SIGIO, select returns as soon as X events occur, because 
> SIGIO is signaled.

Which X event is that? something related to Emacs and selections, or
just a random event which simply happens at that time?

Anyway, AFAIU, the wait is supposed to end because XTread_socket reads
a SelectionNotify event, and that modifies the cell for which we
wait.  What I'm not sure I understand is how are we supposed to call
XTread_socket when we are stuck inside select all the time?

> 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.

Making timeout shorter might be the solution, but I'd like to
understand the problem better first.

Thanks.

Previous Next

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