Re: Mixing threaded and non-threaded - Mailing list pgsql-hackers

From Steve Atkins
Subject Re: Mixing threaded and non-threaded
Date
Msg-id 20040130171406.GA20473@gp.word-to-the-wise.com
Whole thread Raw
In response to Re: Mixing threaded and non-threaded  (Scott Lamb <slamb@slamb.org>)
List pgsql-hackers
On Fri, Jan 30, 2004 at 11:10:49AM -0600, Scott Lamb wrote:
> On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote:
> >Manfred Spraul wrote:
> >>Bruce Momjian wrote:
> >>
> >>>Woh, as far as I know, any application should run fine with 
> >>>-lpthread,
> >>>threaded or not.  What OS are you on?  This is the first I have 
> >>>heard of
> >>>this problem.
> >>>
> >>>
> >>Perhaps we should try to figure out how other packages handle
> >>multithreaded/singlethreaded libraries? I'm looking at openssl right
> >>now, and openssl never links against libpthread: The caller is
> >>responsible for registering the locking primitives.

I don't think changing the linking approach is a good thing. But a
mention in the documentation might be.
> >We perhaps don't need -lpthread for creating libpq, but only for ecpg.
> >However, now that we have used thread locking for SIGPIPE, we are now
> >calling pthread from libpq, but only 7.5.
> >
> >However, I still don't understand why the user is seeing a problem and
> >what rewrite he thinks is necessary for his application because pthread
> >is linked in.

I suspect the rewrite needed is to avoid doing Bad Things in the signal
handler.

> I'm 99% certain that any application will work with -lpthread on RedHat 
> Linux. And 95% certain that's true on _any_ platform. There's no 
> pthread_init() or anything; the distinction he was describing between a 
> non-threaded application and a threaded application with only one 
> thread doesn't exist as far as I know.

That may be true for any correctly written application, but it's
certainly not true for any application. The distinction is, at the
very least, that some system calls are wrapped with mutexes.

> And he mentioned that the deadlocks are occurring in a SIGCHLD handler. 
> Since so few functions are async signal-safe (I doubt anything in libpq 
> is), the code in question was broken before; the extra locking is just 
> making it more obvious.

I tend to agree. However, while it may have been broken before, it
worked flawlessly in multiple production environments on several
different operating systems for several years when not linked with
pthread.

Cheers, Steve


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Next
From: Tom Lane
Date:
Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint