HighResolutionTimer::Pimpl potential bug

MacOSX and iOS
1


Juce 3.2.0  Mac OS 10.10.5

I've just started a Juce project that requires a high resolution timer thread.  I noticed what seems to be an inconsistency in handling OS X "absolute time" in  juce_posix_SharedCode.h

In setThreadToRealtime we have this:

#if JUCE_MAC || JUCE_IOS
        thread_time_constraint_policy_data_t policy;
        policy.period      = (uint32_t) (periodMs * 1000000);
        policy.computation = 50000;
        policy.constraint  = policy.period;
        policy.preemptible = true;


This is assuming that the absolute time is in units of nanoseconds, which is usually true, but technically we're supposed to be adjusting this
by mach_timebase_info_data_t, which you do correctly when calculating the Clock wait delta:


  #if JUCE_MAC || JUCE_IOS
        Clock (double millis) noexcept
        {
            mach_timebase_info_data_t timebase;
            (void) mach_timebase_info (&timebase);
            delta = (((uint64_t) (millis * 1000000.0)) * timebase.denom) / timebase.numer;
            time = mach_absolute_time();
        }


The result is the same as long as timebase.denom and timebase.numer are both 1 but that isn't necessarily the case.  This person thinks it can be different on some iOS devices:

http://iosdeveloperzone.com/2011/05/03/quick-performance-measurements/

Regards,
Jeff

2

Interesting. So I guess you would suggest to change setThreadToRealtime to something like this?


#if JUCE_MAC || JUCE_IOS
    mach_timebase_info_data_t timebase;
    (void) mach_timebase_info (&timebase);

    thread_time_constraint_policy_data_t policy;
    policy.period      = (uint32_t) (periodMs * 1000000 * (timebase.denom / timebase.numer));
    policy.computation = 50000 * (timebase.denom / timebase.numer);
    policy.constraint  = policy.period;
    policy.preemptible = true;

    return thread_policy_set (pthread_mach_thread_np (thread),
                              THREAD_TIME_CONSTRAINT_POLICY,
                              (thread_policy_t) &policy,
                              THREAD_TIME_CONSTRAINT_POLICY_COUNT) == KERN_SUCCESS;