This is the mail archive of the libc-alpha@sourceware.org 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?


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


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