This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is adding a pthread wrapper for sched_{get,set}attr feasible?

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).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]