On Sun, Oct 25, 2015 at 11:47:04AM +0100, Florian Weimer wrote:
> On 10/25/2015 11:41 AM, Theodore Ts'o wrote:
> > On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote:
> >>
> >> Hm, that's weird - all our sched_*() system call APIs that set task
> >> scheduling
> >> priorities are fundamentally per thread, not per process. Same goes for
> >> the old
> >> sys_nice() interface. The scheduler has no real notion of 'process', and
> >> certainly
> >> not at the system call level.
> >>
> >
> > I suspect the main issue is that the games programmers were trying to
> > access it via libc / pthreads, which hides a lot of the power
> > available at the raw syscall level. This is probably more of a
> > "tutorial needed for userspace programmers" issue, at a guess.
>
> If this refers to the lack of exposure of thread IDs in glibc, we are
> willing to change that on glibc side. The discussion has progressed to
> the point where it is now about the question whether it should be part
> of the GNU API (like sched_setaffinity), or live in glibc as a
> Linux-specific extension (like sched_getcpu). More input is certainly
> welcome.
Well, I was thinking we could just teach them to use
"syscall(SYS_gettid)".
On a different subject, I'm going to start telling people to use
"syscall(SYS_getrandom)", since I think that's going to be easier than
having asking people to change their Makefiles to link against some
Linux-specific library, but that's a different debate, and I recognize
the glibc folks aren't willing to bend on that one.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
