This is the mail archive of the glibc-bugs@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]

[Bug libc/14829] sched_* functions wrongly alter thread scheduling, rather than process


http://sourceware.org/bugzilla/show_bug.cgi?id=14829

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
Carlos, there are major issues with your proposed solution. I know this one
applies to musl and I believe it also applies to glibc: the set_tid_address
syscall, used when initializing the main thread's TLS, returns the tid, which
is also the pid; to avoid an additional wasteful getpid syscall, this value is
used for filling in both the tid and pid fields in the TCB. If the kernel were
changed so that the main thread's tid were different from its pid, existing
code would experience subtle but serious breakage. I think such a change would
be contrary to kernel policy.

I also disagree with the claim "These functions do operate correctly for
non-threaded applications." The POSIX requirements for sched_* are essentially
that they do nothing, even for single-threaded applications:

"For threads with system scheduling contention scope, the process scheduling
attributes shall have no effect on the scheduling attributes or behavior either
of the thread or an underlying kernel scheduling entity dedicated to that
thread."

Since Linux only supports system scheduling contention scope, not process
scheduling contention scope, the above text applies even to the main thread of
a single-threaded process.

Even if the process scheduling contention scope were supported, I don't think
the semantics would match the current Linux sched_* syscalls.

If it's desirable to support the Process Scheduling option of POSIX, I think
Linux needs to add new syscalls (perhaps named posix_sched_*), not just adjust
the target scope of the current ones based on whether the argument is a pid or
a tid. Short of that, I'm not entirely sure what the appropriate course of
action for glibc is. I think a good first step would be to redefine
_POSIX_PRIORITY_SCHEDULING to -1, reflecting that glibc does not support the
Process Scheduling option even at compile-time. With this macro defined as -1,
the implementation is not required to provide sched_* functions, and if these
functions do happen to exist as they do in glibc, the implementation is under
no obligation to endow them with semantics matching the POSIX semantics. This
would at least fix the conformance issue and make conforming applications aware
that they cannot use these functions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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