Is adding a pthread wrapper for sched_{get,set}attr feasible?
Szabolcs Nagy
szabolcs.nagy@arm.com
Wed Aug 22 14:37:00 GMT 2018
On 22/08/18 15:32, Juri Lelli wrote:
> On 22/08/18 15:03, Szabolcs Nagy wrote:
>> On 22/08/18 14:15, Juri Lelli wrote:
>>> During a recent discussion on linux-rt-users mailing list [1] was
>>> pointed out that adding a pthreads wrapper around sched_{get,set}attr
>>> syscalls would make life a little easier (and code cleaner?) for users
>>> of such interface.
>>>
>>> One can of course easily use the interface by doing gettid() and calling
>>> syscall() - e.g., [2] - but properly supporting the same interface in
>>> standard libraries might be to prefer, as it would also align with the
>>> existing pthread_attr_setschedparam(), etc.
>>>
>>> I researched a bit the archives, but couldn't find anything related to
>>> this question. Any pointers? Any thoughts about the feasibility of
>>> adding such support?
>>>
>>
>> a linux specific syscall wrapper may work, but it can be done
>> without a new api as well:
>>
>> the existing pthread_attr_setschedparam can be used, but the abi and api
>> has to change, so new symbol versions and feature test macros have to
>> be added (similar to the _POSIX_THREAD_SPORADIC_SERVER macro in unistd.h)
>>
>> glibc misses some members in struct sched_param that are required
>> for the new linux specific SCHED_* policy. (e.g. posix specifies
>> further members for SCHED_SPORADIC which is currently not implemented
>> by linux, but once that's implemented the members have to be added)
>>
>> then pthread_attr_setschedparam could internally call the new
>> linux syscalls.
>
> OK, I guess I'm still wondering though if a new
> pthread_attr_{set,get}schedattr() wouldn't be to prefer, as
> sched_{set,get}attr are supersets of sched_{set,get}param and not the
> other way around?
>
in the pthread spec sched_param was inteded to hold all
sched related parameters.
linux internally did something else, glibc may or may not
want to expose that to users.
the main ugliness about reusing sched_param is that it's
an abi break, the main ugliness about sched_attr is that
it is linux specific so you need linux specific api to
work with it. (pthread_* is posix namespace, not for linux).
More information about the Libc-alpha
mailing list