public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15088] New: glibc wrongly defines _POSIX_PRIORITY_SCHEDULING Date: Thu, 31 Jan 2013 07:11:00 -0000 [thread overview] Message-ID: <bug-15088-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15088 Bug #: 15088 Summary: glibc wrongly defines _POSIX_PRIORITY_SCHEDULING Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: unassigned@sourceware.org ReportedBy: bugdal@aerifal.cx CC: drepper.fsp@gmail.com Classification: Unclassified The _POSIX_PRIORITY_SCHEDULING macro is specified by POSIX to indicate that the implementation supports the Process Scheduling [PS] option group, documented here: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04 On Linux, glibc defines _POSIX_PRIORITY_SCHEDULING, but does not implement the Process Scheduling functionality of POSIX; Linux does not even support the required functionality. What's worse, glibc DOES provide functions with the same names as the functions in the Process Scheduling group (sched_*), but the glibc semantics for these functions are radically different from those specified in Process Scheduling. In particular, the glibc functions do not take a process id as their argument; they take a kernelspace tid, which is not even available to applications because glibc does not provide gettid(). Even if passed the pid (which is also the tid of the main thread), these functions only change the scheduling properties for a single thread, not for the process. Linux does not even support process-level scheduling options, only thread-level ones. Since it doesn't seem realistic to remove the erroneous functionality the sched_* functions are providing now, I think a reasonable solution would be to redefine _POSIX_PRIORITY_SCHEDULING to -1 or 0 and have sysconf return -1 for it. If glibc does not advertise support the the Process Scheduling option, then it's under no obligation to provide the standard sched_* functions, nor to avoid providing conflicting functions with the same names. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2013-01-31 7:11 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-31 7:11 bugdal at aerifal dot cx [this message] 2014-06-13 18:55 ` [Bug libc/15088] " fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-15088-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).