Приоритет планирования каждого потока в Linux с политикой планирования по умолчанию (SCHED_OTHER)

Я пытаюсь реализовать кросс-платформенную оболочку для настройки приоритета текущего потока; в POSIX «правильная» вещь выглядит примерно так:

/// set the priority adjustment for the current thread
/// @param pri  priority between -2 and 2; 0 is the "normal" priority
/// @return true if successful
bool czu::set_thread_priority(int pri) {
    struct sched_param sp;
    int policy;
    pthread_t self = pthread_self();
    if (pthread_getschedparam(self, &policy, &sp) != 0) return false;
    int pmin = sched_get_priority_min(policy);
    int pmax = sched_get_priority_max(policy);
    if (pmin == -1 || pmax == -1) return false;
    sp.sched_priority = pmin + (pmax-pmin) * (pri + 2) / 4;
    return pthread_setschedparam(self, policy, &sp) == 0;
}

Это работает так, как я и ожидал в macOS (где потоки, кажется, имеют диапазон приоритетов [15, 47], по умолчанию 31), но совсем не работает в Linux, как в случае с политикой по умолчанию (0 AKA SCHED_OTHER), диапазон разрешенных приоритетов равно [0, 0], т. е. корректировка приоритетов невозможна.

Вы можете переключить политику планирования на что-то вроде SCHED_FIFO или SCHED_RR и использовать их значения приоритета, но это совсем не то, что я хочу (из man 7 sched они всегда имеют приоритет над SCHED_OTHER задачами, и в целом они подходят для очень специфических сценариев).

Вместо этого я обнаружил, что работает использование значения nice (через nice(2)/setpriority(2)), которое, вопреки тому, что говорит POSIX, зависит от потока, а не от процесса (кажется, довольно прямым следствием очень размытой линии между потоками и процессами в Linux, причем в конечном итоге все это просто «задача» с различными возможными общими вещами с другими задачами). В итоге у меня получилось:

bool czu::set_thread_priority(int pri) {
    if (pri < -2) pri = -2;
    if (pri > 2) pri = 2;
#ifdef _WIN32
    // %pri was conveniently chosen so that it matches SetThreadPriority
    return SetThreadPriority(GetCurrentThread(), pri);
#elif __linux__
    // On Linux the pthread_setschedparam stuff works only with particular
    // scheduling policies, specifically it does not work with the default one;
    // instead, nice(2)/setpriority(2) works, and affects only the current
    // thread instead of doing what POSIX would say (whole process).
    // Here the allowed range is [20, -19] (20 = minimum priority); we can
    // ignore clamping -20 as setpriority is already guaranteed to do it.
    return setpriority(PRIO_PROCESS, 0, pri*-10) == 0;
#else
    struct sched_param sp;
    int policy;
    pthread_t self = pthread_self();
    if (pthread_getschedparam(self, &policy, &sp) != 0) return false;
    int pmin = sched_get_priority_min(policy);
    int pmax = sched_get_priority_max(policy);
    if (pmin == -1 || pmax == -1) return false;
    sp.sched_priority = pmin + (pmax-pmin) * (pri + 2) / 4;
    return pthread_setschedparam(self, policy, &sp)) == 0;
#endif
}

это кажется достаточно хорошим, но потом я заметил в man 2 setpriority:

Согласно POSIX, значение nice — это настройка для каждого процесса. Однако в текущей реализации потоков POSIX в Linux/NPTL значение nice является атрибутом каждого потока: разные потоки в одном процессе могут иметь разные значения nice. Переносимым приложениям не следует полагаться на поведение Linux, которое в будущем может быть приведено в соответствие со стандартами.

Итак, если я хочу быть ориентированным на будущее, но при этом иметь возможность регулировать приоритет потоков с помощью SCHED_OTHER политики планирования по умолчанию, что мне следует делать?

На ум приходит возможность работать в резервном режиме: запустите танец sched_get_priority_min/sched_get_priority_max, и если окажется, что это [0,0] И мы находимся в Linux, предположим, что мы находимся в ситуации, когда хорошее значение соответствует поток (идея состоит в том, что если значение nice когда-либо создается для каждого потока, материал pthreads должен начать работать должным образом, с диапазоном пригодных значений).

bool czu::set_thread_priority(int pri) {
    if (pri < -2) pri = -2;
    if (pri > 2) pri = 2;
#ifdef _WIN32
    // %pri was conveniently chosen so that it matches SetThreadPriority
    return SetThreadPriority(GetCurrentThread(), pri);
#else
    struct sched_param sp;
    int policy;
    pthread_t self = pthread_self();
    // on POSIX the admissible priorities range isn't fixed, and depends from
    // the scheduler policy for the thread; let's figure all this out
    if (pthread_getschedparam(self, &policy, &sp) != 0) return false;
    int pmin = sched_get_priority_min(policy);
    int pmax = sched_get_priority_max(policy);
    if (pmin == -1 || pmax == -1) return false;
#ifdef __linux__
    if (pmax - pmin == 0) {
        // On Linux the pthread_setschedparam stuff works only with particular
        // scheduling policies, specifically it does not work with the default
        // one; instead, nice(2)/setpriority(2) works, and affects only the
        // current thread instead of doing what POSIX would say (whole process).
        // Here the allowed range is [20, -19] (20 = minimum priority); we can
        // ignore clamping -20 as setpriority is already guaranteed to do it.
        return setpriority(PRIO_PROCESS, 0, pri*-10) == 0;
    }
#endif
    // plain linear interpolation
    sp.sched_priority = pmin + (pmax-pmin) * (pri + 2) / 4;
    return pthread_setschedparam(self, policy, &sp) == 0;
#endif
}

Есть ли какая-то лучшая возможность/API, которую я пропустил?