Initial thread stack size (Was: postgresql port, link with libc_r
tobez at tobez.org
Fri Jan 18 02:59:35 PST 2008
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,
> 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
> - 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,
> - 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.
We're going for 'working' here. 'clean' is for people with skills...
-- Flemming Jacobsen
More information about the freebsd-hackers