bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly

[Ken Brown]

On 11/17/2021 11:57 AM, Eli Zaretskii wrote:
> > Date: Wed, 17 Nov 2021 09:59:35 -0500
> > Cc: larsi@gnus.org, 50043@debbugs.gnu.org
> > From: Ken Brown <kbrown@cornell.edu>
> >
> > > But maybe it will be better to do it the same way we
> > > decrease the timeout when a timer is expected to expire before the
> > > timeout: we decrease the timeout, but still remember its value, and
> > > don't return from waiting before the timeout unless there really was
> > > some input.  This would avoid affecting unrelated features such as
> > > accept-process-output.
> >
> > I think that's already taken care of.  The timeout is recalculated on each
> > iteration of the main while loop:
> >
> >         /* Compute time from now till when time limit is up.  */
> >         /* Exit if already run out.  */
> >         if (wait == TIMEOUT)
> >         {
> >           if (!timespec_valid_p (now))
> >             now = current_timespec ();
> >           if (timespec_cmp (end_time, now) <= 0)
> >             break;
> >           timeout = timespec_sub (end_time, now);
> >         }
> >         else
> >         timeout = make_timespec (wait < TIMEOUT ? 0 : 100000, 0);
> >
> > My reduction of timeout to 25 msec occurs after this.
>
> So the result will be that on systems without USABLE_SIGIO we loop
> more times with shorter timeouts for select?

Yes.

> If so, it SGTM.

Thanks, I've pushed that change.

There's still one more issue related to this bug, which I mentioned earlier: If 
x_selection_timeout is zero, x_get_foreign_selection will call 
wait_reading_process output with an infinite timeout rather than a zero timeout, 
which I'm sure is not what was intended.  The attached patch fixes that.

Ken

0001-Avoid-an-accidental-use-of-an-infinite-timeout.patch
Description: Text document