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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
