This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is adding a pthread wrapper for sched_{get,set}attr feasible?
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Juri Lelli <juri dot lelli at redhat dot com>, nd at arm dot com, libc-alpha at sourceware dot org
- Date: Wed, 22 Aug 2018 23:00:04 +0200
- Subject: Re: Is adding a pthread wrapper for sched_{get,set}attr feasible?
- References: <20180822131514.GB27801@localhost.localdomain> <8aea7a69-0638-1c20-fa56-e5f27eaf484b@arm.com> <20180822143244.GC27801@localhost.localdomain> <1abf6029-9406-ae3d-f9e8-7cd9c687a928@arm.com>
* Szabolcs Nagy:
> 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).
We can add pthread_*_np functions, there is precedent for that.
What's unclear to me is what the expected evolution of struct
sched_attr is. Is the description in the manual page accurate?
If we had a pthread_attr_setschedattr_np function, it presumably would
have to make a copy of the argument on the heap, to be consistent with
other such functions. In order to make this future-proof, we would
need a precise description of the extension mechanism, and a promise
that later versions will not contain pointers (which would be unlikely
for such kernel data structures, but it would not be entirely
impossible to have them).