From owner-freebsd-threads@FreeBSD.ORG Mon Apr 30 08:15:59 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90AD31065677; Mon, 30 Apr 2012 08:15:59 +0000 (UTC) (envelope-from chris.hall@highwayman.com) Received: from anchor-post-1.mail.demon.net (anchor-post-1.mail.demon.net [195.173.77.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECE28FC1B; Mon, 30 Apr 2012 08:15:59 +0000 (UTC) Received: from [80.177.246.130] (helo=hestia.halldom.com) by anchor-post-1.mail.demon.net with esmtp (Exim 4.69) id 1SOllw-0002cv-gw; Mon, 30 Apr 2012 08:15:52 +0000 Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SOllv-0002Wa-Cg; Mon, 30 Apr 2012 08:15:51 +0000 From: "'Chris Hall'" Sender: "Chris Hall" To: References: <056201cd253c$b43a0860$1cae1920$@highwayman.com> <4F9CE463.5070501@freebsd.org> In-Reply-To: <4F9CE463.5070501@freebsd.org> Date: Mon, 30 Apr 2012 09:15:46 +0100 Organization: Highwayman Message-ID: <062501cd26a9$74b6adb0$5e240910$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7TYdqFNljrxftDPHrzsix4zy6ZwH7l5dtl8bXdxA= Content-Language: en-gb Cc: Subject: RE: Trying to set PTHREAD_SCOPE_SYSTEM X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 08:15:59 -0000 Julian Elischer wrote (on Sun 29-Apr-2012 at 07:49 +0100): ... > AS far as I know the default is PTHREAD_SCOPE_SYSTEM now. > we no longer support PTHREAD_SCOPE_PROCESS as far as I know. > (I may be confused of course.. it wouldn't be the first time). Ah. Well, that certainly finesses all the issues. > We used to have the ability to switch but the complexity was not > worth the added benefit. Not surprised. Particularly as it all seems so badly defined :-( For my application I would be happy to have a mechanism to give some higher priority to the I/O driven threads, and to lower the priority of the garbage collector and scanning threads. The higher priority stuff ought to be system scope, the lower could be process scope. The POSIX defined stuff almost but not quite provides that, but is so full of implementation-defined and not defined at all, that it seems quite useless to me. Thanks, Chris