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 23:00, Florian Weimer wrote:
> * 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.

FWIW, I agree.

> What's unclear to me is what the expected evolution of struct
> sched_attr is.  Is the description in the manual page accurate?

I'd say so. :-)

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

Man pages are accurate AFAICS [1].

One could also look at a proposed extension that is currently under
review (utilclamp [2]) to have an idea of how future further extensions
will be handled.

I don't see how pointers in there would be required, but I guess only
maintainers can make such a promise?


- Juri

1 -
2 -

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