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