From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 09:04:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BA2637B401; Sun, 25 May 2003 09:04:20 -0700 (PDT) Received: from posgate.acis.com.au (posgate.acis.com.au [203.14.230.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D81F443F93; Sun, 25 May 2003 09:04:17 -0700 (PDT) (envelope-from andymac@bullseye.apana.org.au) Received: from bullseye.apana.org.au (dialup-2.aaa.net.au [203.14.230.67]) by posgate.acis.com.au (8.12.7/8.12.7) with ESMTP id h4PG4BGk012855; Mon, 26 May 2003 02:04:13 +1000 Received: from bullseye.apana.org.au (localhost.apana.org.au [127.0.0.1]) h4PG4W1F056979; Mon, 26 May 2003 02:04:35 +1000 (EST) (envelope-from andymac@bullseye.apana.org.au) Received: from localhost (andymac@localhost)h4PDFGNn052350; Sun, 25 May 2003 23:15:16 +1000 (EST) Date: Sun, 25 May 2003 23:15:16 +1000 (EST) From: Andrew MacIntyre To: freebsd-hackers@FreeBSD.org Message-ID: <20030525220222.K52253@bullseye.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) cc: alane@FreeBSD.org Subject: setting stacksize in "initial" thread (pthreads, 4.8R) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 16:04:20 -0000 I have a situation with a Python interpreter built from Python CVS sources that is hitting the stack limit for the "initial" thread imposed by libc_r: PTHREAD_STACK_INITIAL in /usr/src/lib/libc_r/uthread/pthread_private.h is set to 1MB (0x100000). Compiler optimisation settings do affect whether Python's internal stack check activate before the hard limit bites, and more recent versions of gcc (than the stock gcc in 4.8R) are more aggressive users of stack. I have not been able to find any documented way to control the stacksize of the "initial" thread either programmatically, via a compile/link option or by way of a resource limit in login.conf. Is this possible without rebuilding libc_r? I don't yet have a 5.x install to check the situation - does the new libthr/libkse setup differ in respect to the above? Using the Linuxthreads port is a workaround for this situation, but I'd rather that it not be necessary to rely on an extra dependancy. Cc'ed to the Python port maintainer for info. Regards, Andrew. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia