Nowhere in the man page of pthread_setschedparam it is mentioned that 0 is a valid value. The example uses pthread_self(), so should we.
(noticed by Anthony Towns) Fixes #12915.
Nowhere in the man page of `pthread_setschedparam` it is mentioned that
`0` is a valid value. The example uses `pthread_self()`, so should we.
(noticed by Anthony Towns)
@eklitzke Mind to take a look here?
Concept ACK cff66e6a29 (fixes the issue for me, didn't review though)
utACK cff66e6a29d700188f6ecebeaacc8bcaa1fc1095
So on IRC it was mentioned that
<aj> hmm, i thought designator initialisers (param{.sched_priority=0}) weren't ok for c++11 (http://en.cppreference.com/w/cpp/language/aggregate_initialization says they're c++20 fwiw)
Should I make this change here too? It's curious that it does compile (as our build explicitly passes -std=c++11), but if it's not allowed by the standard we should probably change it.
utACK cff66e6a29d700188f6ecebeaacc8bcaa1fc1095
Neither clang nor gcc seems to warn about designated initializers with c++11. I think this is the only use of one in the codebase currently, so removing it is probably fine.
Although no compiler appears to complain about it, these are
not valid for c++11.
(http://en.cppreference.com/w/cpp/language/aggregate_initialization says they're c++20)
The structure is defined as:
struct sched_param {
int sched_priority;
};
So passing 0 for the first field has the same effect.utACK cff66e6.
Should I make this change here too?
Maybe just fix the problem for now.
Looks good.
utACK b86730a.
utACK b86730a4d74471378fbafb2bac9839110f520b76
I Noticed this aswell.. fixed it with self()