From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3109 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: nice standards complaince issue Date: Sun, 14 Apr 2013 21:45:10 -0400 Message-ID: <20130415014510.GS20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1365990320 6675 80.91.229.3 (15 Apr 2013 01:45:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 01:45:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3113-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 15 03:45:24 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1URYTz-0002tn-Jn for gllmg-musl@plane.gmane.org; Mon, 15 Apr 2013 03:45:23 +0200 Original-Received: (qmail 18247 invoked by uid 550); 15 Apr 2013 01:45:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18239 invoked from network); 15 Apr 2013 01:45:22 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3109 Archived-At: On Sat, Apr 13, 2013 at 11:23:08PM +0100, Justin Cormack wrote: > Since glibc 2.2.4, nice() is implemented as a library function that calls > getpriority(2) to obtain the new nice value to be returned to the > caller. With this implementation, a successful call can legitimately > return -1. To reliably detect an error, set errno to 0 before the call, > and check its value when nice() returns -1. Thanks for the heads-up. Actually, I think there's a much bigger issue with both nice and setpriority: they're affecting one thread rather than the process. This may technically not be non-conforming as long as SCHED_OTHER scheduling is in effect, but it's sketchy. Basically this all stems from a complete failure of Linux to support process contention scope and the [PS] option of POSIX... (despite glibc claiming to support it!) In any case, the issue you reported should be fixed. Do you have a proposed patch? Rich