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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
