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 #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:

* tgkill
- Which could be enhanced to accept a tid, find the tgid, and then kill the
associated group.

* rt_tgsigqueueinfo
- 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
broken.

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

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.


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