Initial thread stack size (Was: postgresql port, link with libc_r or not?)

[Anton Berezin]

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