From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 10:59:35 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49BA16A41A for ; Fri, 18 Jan 2008 10:59:35 +0000 (UTC) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [194.255.56.42]) by mx1.freebsd.org (Postfix) with ESMTP id 112BC13C442 for ; Fri, 18 Jan 2008 10:59:34 +0000 (UTC) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id C9CCA125421; Fri, 18 Jan 2008 11:41:34 +0100 (CET) Date: Fri, 18 Jan 2008 11:41:34 +0100 From: Anton Berezin To: freebsd-hackers@freebsd.org Message-ID: <20080118104134.GB41865@heechee.tobez.org> References: <375FDDD936C407E534A68033@rambutan.pingpong.net> <20080115234339.GB1313@straylight.m.ringlet.net> <20080117135026.GA11444@heechee.tobez.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080117135026.GA11444@heechee.tobez.org> X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.17 (2007-11-01) Cc: girgen@FreeBSD.org Subject: Initial thread stack size (Was: postgresql port, link with libc_r or not?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 10:59:35 -0000 Following an advice from Kris, moving this to a more appropriate list. On Thu, Jan 17, 2008 at 02:50:26PM +0100, Anton Berezin wrote: > On Wed, Jan 16, 2008 at 01:43:39AM +0200, Peter Pentchev wrote: > > On Tue, Jan 15, 2008 at 04:22:06PM +0100, Palle Girgensohn wrote: > > > > I need some advice. When configuring postgresql, I can set > > > "--enable-thread-safe", which links libpq.so (the postgresql client > > > library) with libc_r, and makes libpq thread safe. > > > > > > Postgresql itself is not threaded, but uses processes only. But if a client > > > library is threaded, and links with libpq, it will get into trouble unless > > > libpq is build thread safe. > > > > > > I'm wondering, are there any drawbacks leaving this on per default? > > > > The main problem I've seen with other thread-safe libraries (now why > > does Perl come to mind, I wonder... but there were others, too) were... > > wait for it... other libraries :) > > Perl comes to mind probably because I've done exactly the same thing that > Palle is considering now to do with PostgreSQL port to lang/perl5.8 5.8.7 or > 5.8.6, some time ago. This turned out not be a good idea because of the > initial thread stack size. > > When you don't do this, you get, for most intents, an "unlimited" stack size > (unless RLIMIT_STACK is in effect). > > When you *do* this, all of a sudden you end up with a quite limited stack > for your main thread. And if you don't use threads as such, and just want > to be "thread safe", this can and will bite you in the ass. > > While our modern defaults (2 MB on 32-bit platforms and twice that on 64-bit > ones) would seem "large enough" for a typical C program, dynamic languages > are a different story. I had to revert the change to lang/perl5.8 after > some popular mail filtering application (either amavisd or Spam Assassin, I > don't recall which) was segfaulting with stack overflow for some people. > > If you google for "thread stack size segfault freebsd", most of the > fountains of frustration you'll discover will be related to Perl, Python, > Tcl. > > The worst of it is, that if you write a "real" threaded program, you have > quite substantial degree of control - you can specify your own stack size, > however large you want it, when you create *new* threads. > > There is no way in FreeBSD to do the same for initial stack size for the > main thread. No runtime, no linktime, no nada nichego. Apparently, the > only way to increase it is to recompile your threaded library, which will > have a system-wide effect. > > What would be a good solution to this? I don't know. Two things come to > mind: > > - make a symbol which holds the initial stack size in our threading > libraries (_thr_stack_initial for libthr and libkse) to have global > scope, and make it weak, so that a program could change it at linktime, > > or > > - do not allocate stacks for threads other than the main thread on the > system stack; leave the system stack to the main thread; allocate > thread stacks using malloc. > > I was meaning to start this discussion for some time. This seems to be as > good opportunity as any. > > Cheers, > \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen