Re: About ceph_clock_now()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25-1-2016 21:14, Adam C. Emerson wrote:
> On 25/01/2016, Willem Jan Withagen wrote:
>> 1)
>> Currently the code in Adam's looks like:
>> #if defined(CLOCK_MONOTONIC_COARSE)
>>         // Linux systems have _COARSE clocks.
>>         clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
>> #elif defined(CLOCK_MONOTONIC_FAST)
>>         // BSD systems have _FAST clocks.
>>         clock_gettime(CLOCK_MONOTONIC_FAST, &ts);
>> #else
>>         // And if we find neither, you may wish to consult your system's
>>         // documentation.
>> #warning Falling back to CLOCK_MONOTONIC, may be slow.
>>         clock_gettime(CLOCK_MONOTONIC, &ts);
>> #endif
>>
>> And this is repeated in a few more locations.
>> Moreover, it will be required to do that a few times everytime
>> clock_getime is used.
> 
> I was originally thinking of just specifying the time constant, but I figured
> that somehow somewhere someone might want to compile on a system without
> clock_gettime. (Windows? I don't know.) Or use the fasttime library or something
> where just switching out the constant wouldn't work.
> 
> I wouldn't worry about people having to do this every tie they call
> clock_gettime, though, since they really ought to be going through the C++ Clock
> abstraction. (At least, in the context of the Ceph codebase.)
> 
Well that is the essential part of all of this. If other parts of the
Ceph code are expected to go through the ceph_time abstraction, then
this is the only place we need to care for OS differences. And the more
clear and obvious, the better it is.

And we should stick with your version.

--WjW

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux