(This problem was found by analyzing a failure of LSB distribution compliance test, lsb-runtime, v. 4.0.2.) A relatively new change in $GITROOT/glibc/nptl/pthread_attr_setschedparam.c (2009-04-23 according to git) adds a check to pthread_attr_setschedparam() call whether the priority being set is compatible with the scheduling policy already set in the structure; if the priority is not in the prescribed range, it fails, generating the EINVAL error. This check, although well intended, has a side effect that can break existing code (at least the LSB tests): it makes the process of initializing a pthread_attr structure order-dependent on Linux. As Linux does not use the numeric priority for SCHED_OTHER, which is the default, and sched_get_priority_min() and sched_priority_max() return 0. Therefore: If a programmer calls pthread_attr_init(), then pthread_attr_setschedpolicy() to set SCHED_RR or SCHED_FIFO, and then pthread_attr_setschedparam(), it works. But if the other way around (priority first, then scheduling policy), it fails for "no apparent reason".
File a bug with the LSB, as usual their code is broken.
I agree, LSB tests are often broken. But in this specific case, I'd say the programmer did nothing wrong. POSIX does not specify that the pthread_attr structure should be filled in a specific order, and the EINVAL error in the case of wrong order is hard to explain (the incorrect priority is not an error *yet*; it would become an error in the moment of thread creation, but before this, the values in the structure can still be changed). Could you please consider this problem once more? If you still have the same opinion, I will open the bug with LSB - but I'm afraid the same problem can occur in another codes, as well. Thank you for your patience.
Problem also reported in LSB bugzilla: http://bugs.linuxbase.org/show_bug.cgi?id=2784 (which seems equivalent to http://bugs.linuxbase.org/show_bug.cgi?id=2663)
we actually already track this *** This bug has been marked as a duplicate of 7013 ***