Closed cmikk closed 7 years ago
I'm kinda confused by this. Why should the use of clock_gettime
be conditional on pthread_condattr_setclock
? That prevents any non- pthread_cond_timedwait()
related uses of clock_gettime
, e.g. in fstrm__iothr_maybe_open()
.
@edmonds - I had missed those uses of clock_gettime()
in my review.
The core issue is that HAVE_CLOCK_GETTIME
presumes pthread_condattr_setclock()
exists, which is not necessarily the case. I've pushed a more correct fix to the branch head.
@cmikk I think the #ifdef
in fstrm__iothr_thr()
also needs an && HAVE_PTHREAD_CONDATTR_SETCLOCK
?
https://github.com/farsightsec/fstrm/blob/v0.3.1/fstrm/iothr.c#L614-L623
Agreed, and fixed.
AC_CHECK_FUNCS([clock_gettime, pthread_condattr_setclock])
is broken. See the comma in the functions list. The configure output shows it too and the config.out shows errors like
#undef clock_gettime,
^
//
conftest.c:52:22: error: expected identifier or '('
The typo @reedjc pointed out made the builds (and checks) work by disabling clock_gettime()
entirely. Correcting the typo exposed an error in the #ifdef
fix, which required a different choice of default clock for clock_gettime()
.
My research indicated that if pthread_condattr_setclock()
is not available to say otherwise, pthread_cond_timedwait()
uses CLOCK_REALTIME
. I amended the #ifdef
fix to use CLOCK_REALTIME
for deadline computation if clock_gettime()
is available but pthread_condattr_setclock()
is not, squashed in a fix to the erroneous ',' in configure.ac, and pushed a clean branch to replace the old branches/issue34
.
Check for the existence of
pthread_condattr_setclock
in addition toclock_gettime
.