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

Previous Next

Full log

Message #26 received at 50043 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 50043 <at> debbugs.gnu.org
Subject: Re: bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work
 correctly
Date: Mon, 15 Nov 2021 14:26:08 -0500

On 11/15/2021 12:24 PM, Eli Zaretskii wrote:
>> 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?

Setting x-selection-timeout to zero actually makes the timeout infinite:

  if (time_limit < 0 || nsecs < 0)
    wait = MINIMUM;
  else if (time_limit > 0 || nsecs > 0)
    {
      wait = TIMEOUT;
      now = current_timespec ();
      end_time = timespec_add (now, make_timespec (time_limit, nsecs));
    }
  else
    wait = FOREVER;         <<<<<<<<<<<<<<<<<<<<<<

If x-selection-timeout is zero and you really want select to use a timeout of 
zero, you have to specify a negative value for nsecs.  [This strikes me as very 
counterintuitive and a poor design decision.]  x_get_foreign_selection should 
probably be changed to account for this, since the default value of 
x-selection-timeout is in fact zero, and clearly the intention was not to have 
an infinite wait in this case.  There's a comment in x_get_foreign_selection 
that says "don't wait forever".

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

I guess it's whatever X event is supposed to come in reply to the call

  XConvertSelection (display, selection_atom, type_atom, target_property,
		     requestor_window, requestor_time);

in x_get_foreign_selection.  I don't anything about how I/O works under X, so I 
can't be more specific.

> 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're never stuck for more than 2 seconds [when there's no SIGIO] because 
poll_timer fires and either sends SIGALRM or makes timerfd read ready.  Either 
way, select returns, and the next iteration of the main loop checks for input 
and checks for a cell change.

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

Ken

Previous Next

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