public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/14829] sched_* functions wrongly alter thread scheduling, rather than process
Date: Fri, 14 Jun 2013 16:36:00 -0000	[thread overview]
Message-ID: <bug-14829-131-YBSxu3ibk0@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-14829-131@http.sourceware.org/bugzilla/>

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
I agree that this a mess in Linux right now.

I agree that most of the sched_* functions should actually do nothing in glibc,
principally because process level contention scheduling is not supported.

At present these functions change the scheduling for the thread leader whose
tid == tgid and which is returned from the call to getpid(). I agree that this
is wrong according to POSIX. Thus the functions do not operate as required by
POSIX for threaded applications

These functions do operate correctly for non-threaded applications.

One solution is to version the interfaces, and have all of the new version do
nothing if threads are active.

When Linux gets proper process scheduling support we can stop doing nothing and
do the right sequence of operations to set the pid's (or tgid's) scheduling
parameters.

Linux needs to be enhanced to do the following:
- getpid returns pid
- gettid returns tid != pid

All processes whould start off with a unique tgid that can be used as the
target of these calls and that is returned via getpid, and that can't be
confused with the thread leader.

That would allow these calls to identify the tgid uqiquely.

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


  reply	other threads:[~2013-06-14 16:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-11 19:31 [Bug libc/14829] New: " bugdal at aerifal dot cx
2013-06-14 16:36 ` carlos at redhat dot com [this message]
2013-06-16  4:46 ` [Bug libc/14829] " bugdal at aerifal dot cx
2013-06-17 19:34 ` carlos at redhat dot com
2013-06-17 20:02 ` bugdal at aerifal dot cx
2013-06-17 20:44 ` carlos at redhat dot com
2013-06-17 21:02 ` bugdal at aerifal dot cx
2014-06-14 11:11 ` fweimer at redhat dot com
2014-06-17 12:47 ` fweimer at redhat dot com
2014-06-17 13:54 ` bugdal at aerifal dot cx

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-14829-131-YBSxu3ibk0@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: link
Be 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).