[nut-Patches][313714] Use monotonic clock for monitoring

nut-patches at alioth.debian.org nut-patches at alioth.debian.org
Wed Jul 11 02:20:23 UTC 2012


nut-Patches item #313714, was changed at 2012-07-10 22:20 by Charles Lepple
You can respond by visiting: 
https://alioth.debian.org/tracker/?func=detail&atid=411544&aid=313714&group_id=30602

Status: Open
Priority: 3
Submitted By: Baruch Even (baruch)
Assigned to: Nobody (None)
Summary: Use monotonic clock for monitoring 
Category: None
Group: None
Resolution: None


Initial Comment:
The current logic uses time(2) to decide whether it is time to monitor again or not, however if the time is moved backwards monitoring will cease to be performed until the time difference is caught up. The attached patch switches the code to clock_gettime(2) using CLOCK_MONOTONIC.



----------------------------------------------------------------------

>Comment By: Charles Lepple (clepple-guest)
Date: 2012-07-10 22:20

Message:
So I don't forget, there's some information on mach_absolute_time() on OS X here:

http://developer.apple.com/library/mac/#qa/qa1398/_index.html

----------------------------------------------------------------------

Comment By: Baruch Even (baruch)
Date: 2012-07-10 03:09

Message:
I'll wrap the clock_gettime with a runtime logic to handle fallback in case of problems. I've also seen mentions that MacOSX doesn't have clock_gettime at all.

To ease my work a bit I pushed a git repo with my changes at https://github.com/baruch/nut please review the changes there. When things will be acceptable I'll squash the patches to a single change.

----------------------------------------------------------------------

Comment By: Charles Lepple (clepple-guest)
Date: 2012-07-09 09:02

Message:
Agreed that the manpage doesn't say it is not supported. I'm just thinking that if the monotonic clock source isn't available (at runtime) then the code should fall back to CLOCK_REALTIME, which is mandatory. The autoconf check is necessary but not sufficient, and I'd rather not swap one potential bug for another if we can solve both at once.

Maybe put the fallback code into a function in common/common.c?

Haven't had a chance to test the code myself, but the rest of the implementation sounds good.

----------------------------------------------------------------------

Comment By: Baruch Even (baruch)
Date: 2012-07-09 08:50

Message:
The Oracle manpage doesn't say it is not supported, this will need to be checked in the autoconf scripts I guess and be made to work with a fallback to another clock type that is usable. It should be noted that without a monotonic clock source the bug can't really be solved, though it can be cured for most likely cases (f.ex. by checking the difftime with an abs() call).

I'm first looking for feedback on the approach and then I can refine the solution to work better across all platforms.

----------------------------------------------------------------------

Comment By: Charles Lepple (clepple-guest)
Date: 2012-07-09 08:46

Message:
The patch ignores the return value of clock_gettime(). Probably not a concern for Linux or FreeBSD, but Solaris documentation (for instance) does not list CLOCK_MONOTONIC:

http://docs.oracle.com/cd/E19109-01/tsolaris7/805-8069/6j7j9vnt1/index.html

----------------------------------------------------------------------

You can respond by visiting: 
https://alioth.debian.org/tracker/?func=detail&atid=411544&aid=313714&group_id=30602



More information about the NUT-tracker mailing list