GNU bug report logs - #32746
stop using obsolescent setitimer API

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32746 in the body.
You can then email your comments to 32746 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Subject: stop using obsolescent setitimer API
Date: Sun, 16 Sep 2018 13:19:45 -0700

[Message part 1 (text/plain, inline)]

POSIX obsoleted the getitimer/setitimer API a decade ago, and now's a good time 
for Emacs to stop using this obsolescent API, partly to simplify other timestamp 
improvements that I have in mind, partly to head off any other lurking bugs like 
the problem I just fixed in commit 238c7cd730819ddba2dbde3c46ee36136575695b 
relating to a mistaken assumption about the old API.

Attached please find two proposed patches. The first simplifies Emacs proper to 
just use the current timer_gettime/timer_settime API instead (this is the 
standard replacement for the obsolescent API). The second patch affects only the 
MS-Windows code, modifying it to use the new API instead of the old one; I 
haven't tested it as I don't use MS-Windows.

[0001-Simplify-by-not-worrying-about-setitimer.patch (text/x-patch, attachment)]

[0002-Adjust-w32-to-emulate-timer_settime-not-setitimer.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 32746 <at> debbugs.gnu.org
Cc: Emacs-devel <at> gnu.org
Subject: Re: setitimer API is obsolescent
Date: Mon, 17 Sep 2018 17:47:53 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 16 Sep 2018 13:32:33 -0700
> 
> POSIX made the getitimer/setitimer API obsolescent a decade ago, and now's a 
> good time for Emacs to rely on the current timer_gettime/timer_settime API 
> instead. I've proposed patches for this in Bug#32746. If you know a platform 
> that is a current porting target of Emacs and lacks timer_gettime/timer_settime 
> but has getitimer/setitimer, please send email to <32746 <at> debbugs.gnu.org> about 
> it. (MS-Windows lacks both APIs; the proposed patches attempt to address that 
> special case.)

Thanks, I will send my comments to the MS-Windows part of the patch in
a moment.

However, I think it might be too early to remove support for
setitimer, because some platforms have problems with it.  AFAIK, macOS
and some *BSD version either don't have that family or have buggy
implementations.

Supporting the old APIs only needs a couple of #ifdef's in 3 files, so
it doesn't sound like a terrible maintenance burden.

Btw, it would be good to have some tests for these facilities, as
currently we don't have any practical means to make sure we don't
introduce bugs when we switch to alternative APIs.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 32746 <at> debbugs.gnu.org
Subject: Re: bug#32746: stop using obsolescent setitimer API
Date: Mon, 17 Sep 2018 18:01:56 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 16 Sep 2018 13:19:45 -0700
> 
> POSIX obsoleted the getitimer/setitimer API a decade ago, and now's a good time 
> for Emacs to stop using this obsolescent API, partly to simplify other timestamp 
> improvements that I have in mind, partly to head off any other lurking bugs like 
> the problem I just fixed in commit 238c7cd730819ddba2dbde3c46ee36136575695b 
> relating to a mistaken assumption about the old API.
> 
> Attached please find two proposed patches. The first simplifies Emacs proper to 
> just use the current timer_gettime/timer_settime API instead (this is the 
> standard replacement for the obsolescent API). The second patch affects only the 
> MS-Windows code, modifying it to use the new API instead of the old one; I 
> haven't tested it as I don't use MS-Windows.

Thanks, I have a couple of comments/questions about the MS-Windows
changes (thanks for working on that):

> +struct sigevent
>  {
> -  struct  timeval it_interval;	/* timer interval */
> -  struct  timeval it_value;	/* current value */
> +  int sigev_notify;
> +  int sigev_signo;
> +  union sigval sigev_value;
> +  void (*sigev_notify_function) (union sigval);
> +  pthread_attr_t *sigev_notify_attributes;

I'd prefer not to use pthread_attr_t, as that could clash with some
MinGW header.

> +typedef enum { CLOCK_REALTIME, CLOCK_THREAD_CPUTIME_ID } clockid_t;

Some versions of MinGW have clockid_t (for clock_gettime and
clock_settime), so this might cause conflicts.

> +#define CLOCK_REALTIME CLOCK_REALTIME
> +#define CLOCK_THREAD_CPUTIME_ID CLOCK_THREAD_CPUTIME_ID

Some of these are declared/defined in MinGW headers in some versions.

> +  HANDLE thread_hand;

This seems to be unused, and is probably related to the other issues
below.

> -  itimer = (which == ITIMER_REAL) ? &real_itimer : &prof_itimer;
> +  itimer = realtime ? &real_itimer : &prof_itimer;
>  
> -  ticks_now = w32_get_timer_time ((which == ITIMER_REAL)
> +  ticks_now = w32_get_timer_time (realtime
>  				  ? NULL
>  				  : GetCurrentThread ());
>  
> +  itimer = realtime ? &real_itimer : &prof_itimer;
> +
> +  ticks_now = w32_get_timer_time (thread_hand);

This seems to do the same stuff twicer, using thread_hand that is
uninitialized.

> -  expire = value->it_value.tv_sec * TIMER_TICKS_PER_SEC;
> -  usecs = value->it_value.tv_usec;
> -  if (value->it_value.tv_sec == 0
> -      && usecs * TIMER_TICKS_PER_SEC < clocks_min * 1000000)
> +  expire = ex.tv_sec * TIMER_TICKS_PER_SEC;
> +  ns = ex.tv_nsec;
> +  if (ex.tv_sec == 0
> +      && 0 < ns && ns < clocks_min * (1000000000 / TIMER_TICKS_PER_SEC))
>      expire = clocks_min;

This seems to use an undefined variable 'ex'.

> -  expire += ticks_now;
> +  if (flags & TIMER_ABSTIME)
> +    expire += ticks_now;

I don't think I understand the reason for the condition you added.

> +#ifdef HAVE_ITIMERSPEC

If we will have a test for itimerspec, we will probably need to edit
nt/mingw-cfg.site to keep the configure script happy.

Thanks again for working on this.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, 32746 <at> debbugs.gnu.org
Cc: Emacs-devel <at> gnu.org
Subject: Re: setitimer API is obsolescent
Date: Mon, 17 Sep 2018 09:06:43 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:

> However, I think it might be too early to remove support for
> setitimer, because some platforms have problems with it.  AFAIK, macOS
> and some *BSD version either don't have that family or have buggy
> implementations.

In that case never mind about removing use of setitimer. I'm attaching a patch 
against my previous proposal for fixup on the MS-Windows side, in the light of 
your other comments; good luck with it, and feel free to ignore the whole thing 
if it doesn't work. As before, it's untested and no doubt it has problems.

[0001-Patch-inspired-by-Eli-s-review-Bug-32764-10.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 32746 <at> debbugs.gnu.org, Emacs-devel <at> gnu.org
Subject: Re: bug#32746: setitimer API is obsolescent
Date: Mon, 10 Aug 2020 14:12:32 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Eli Zaretskii wrote:
>
>> However, I think it might be too early to remove support for
>> setitimer, because some platforms have problems with it.  AFAIK, macOS
>> and some *BSD version either don't have that family or have buggy
>> implementations.
>
> In that case never mind about removing use of setitimer.

OK; it sounds like the decision was to not do this change any time soon,
so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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