Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

["Torsten Bögershausen" <tboegi@web.de>]

On 2014-09-03 08.27, Johannes Sixt wrote:
> Am 03.09.2014 00:06, schrieb Junio C Hamano:
>> * jt/timer-settime (2014-08-29) 9 commits
>>  - use timer_settime() for new platforms
>>  - autoconf: check for timer_settime()
>>  - autoconf: check for struct itimerspec
>>  - autoconf: check for struct sigevent
>>  - autoconf: check for struct timespec
>>  - autoconf: check for timer_t
>>  - autoconf: check for setitimer()
>>  - autoconf: check for struct itimerval
>>  - git-compat-util.h: add missing semicolon after struct itimerval
>>
>>  Need a rerolled one.
> 
> Yes. Please mark the MinGW build as not having timer_settime. Better
> yet, implement it in compat/mingw.c to replace its setitimer()
> implementation.
> 
> As a bug report, currently, I get
> 
>     CC progress.o
> progress.c: In function 'set_progress_signal':
> progress.c:66: error: 'CLOCK_MONOTONIC' undeclared (first use in this
> function)
> 
> even though I have NO_TIMER_SETTIME set in my config.mak (but no other
> of new configuration options that this series introduces).
> 
> But IMHO, this topic goes in a wrong direction. "Avoid deprecated
> interfaces" is way overrated. It would be preferable (IMHO) to implement
> setitimer() in compat/ for systems that don't have it.
> 
> -- Hannes
 
I tend to agree:

grep "ifeq.*uname_S" config.mak.uname  | wc
reports 21 different OS versions, where Git can use setitimer(),
and that has been working quite well.

The getitimer() function call appeared in 4.2BSD, and even if
POSIX papers recommends the use of timers API (timer_gettime(2), timer_settime(2),
the current implementation in real existing OS may stay available for a long time.

The patch-series is addressing one single system.

Could we think about writing a setitimer() implementation which uses
the new POSIX timer_settime(2) for systems which do not have getitimer() ?

Or is somebody able to test all platforms which currently are supported by Git ?