Re: Mixing threaded and non-threaded

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