This is the mail archive of the
mailing list for the glibc project.
[Bug libc/14829] sched_* functions wrongly alter thread scheduling, rather than process
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 17 Jun 2013 19:34:51 +0000
- Subject: [Bug libc/14829] sched_* functions wrongly alter thread scheduling, rather than process
- Auto-submitted: auto-generated
- References: <bug-14829-131 at http dot sourceware dot org/bugzilla/>
--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #2)
> 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.
The only uses which would break are AFAICT:
- Which could be enhanced to accept a tid, find the tgid, and then kill the
- Same problem.
They can be solved because the expected semantics is that you call these for a
thread group, and if you instead pass a tid, it is a one-way translation from
thread to thread group. Even with cgroups I don't think this invariant is
Did I miss anything?
> 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.
Sorry, let me clarify what I meant to say. With a relatively minor fix we could
support PTHREAD_SCOPE_PROCESS for a single-threaded application. The case of
inter-thread scheduling degenerates to unspecified so as long as we do nothing
for PTHREAD_SCOPE_SYSTEM and do exactly was we do now for
Does that make sense?
> Even if the process scheduling contention scope were supported, I don't
> think the semantics would match the current Linux sched_* syscalls.
It would certainly involve kernel work. At present Linux doesn't support
process scheduling contention scope.
> 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.
Agreed that that is the best way forward.
You are receiving this mail because:
You are on the CC list for the bug.