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

Previous Next

Package: emacs;

Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>

Date: Fri, 13 Aug 2021 11:57:01 UTC

Severity: normal

Found in version 28.0.50

Done: Ken Brown <kbrown <at> cornell.edu>

Bug is archived. No further changes may be made.

Full log


Message #56 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: Wed, 17 Nov 2021 12:25:38 -0500
[Message part 1 (text/plain, inline)]
On 11/17/2021 11:57 AM, Eli Zaretskii wrote:
>> Date: Wed, 17 Nov 2021 09:59:35 -0500
>> Cc: larsi <at> gnus.org, 50043 <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> 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 (text/plain, attachment)]

This bug report was last modified 3 years and 244 days ago.

Previous Next


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