Skip site navigation (1) Skip section navigation (2)

Re: Mixing threaded and non-threaded

From: Scott Lamb <slamb(at)slamb(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Manfred Spraul <manfred(at)colorfullife(dot)com>,Steve Atkins <steve(at)blighty(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Mixing threaded and non-threaded
Date: 2004-01-30 17:10:49
Message-ID: 40364FF0-5347-11D8-8133-000A95891440@slamb.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Some other libraries, such as boost, always link against -lpthread when 
it is present.

I don't think OpenSSL's example is a good one to follow. It's way too 
easy to forget to do that, and then your application is broken. You'll 
have weird crashes that will be hard to figure out. I think OpenSSL was 
made such because pthreads was not so common back in the day; they 
probably wanted to support other threading APIs. That's unnecessary 
now.

Another reason might be to avoid the expense of locks when they are 
unnecessary. But also, I think that is not as necessary as it once was, 
particularly with modern systems like Linux+NPTL having locks cost 
virtually nothing when there is no contention.

> 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'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.

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.

Speaking of async signal-safe functions, pthread_getspecific() isn't 
specified to be (and thus PQinSend() and thus 
sigpipe_handler_ignore_send()). It's probably okay, but libpq is 
technically using undefined behavior according to SUSv3.

Scott Lamb


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-01-30 17:13:55
Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Previous:From: Bruce MomjianDate: 2004-01-30 17:01:37
Subject: Sync vs. fsync during checkpoint

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group