Scott Lamb wrote:
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.
Yikes. I never suspected pthread_getspecific() would not be signal safe because it is already thread safe, but I see the point that it is called in the current thread. Any ideas how to fix this?
A few idea.
When I ran a similar situation in my own code, my approach was to just add a comment to make the assumption explicit. It's quite possible the standard is just overly conservative. Some specific platforms - <http://www.qnx.com/developer/docs/qnx_6.1_docs/neutrino/lib_ref/p/pthread_getspecific.html> - mark it as being async signal-safe.
Searching for "pthread_getspecific signal" on google groups turns up a bunch of other people who have run into this same problem. One person notes that it's definitely not safe on LinuxThreads if you use sigaltstack().
If your platform has SA_SIGINFO, you could - in theory - use the ucontext argument to see if that thread is in a PostgreSQL operation. But I doubt that's portable.
You could just do a pthread_sigmask() before and after the pthread_setspecific() to guarantee that no SIGPIPE will arrive on that thread in that time. I think it's pretty safe to assume that as long as you're not doing a pthread_[gs]etspecific() on that same pthread_key_t, it's safe.
There's one thread function that is guaranteed to be async signal-safe - sem_post(). (Though apparently older LinuxThreads on x86 fails to meet this assumption.) I'm not quite sure what you could do with that, but apparently there's something or they wouldn't have gone to the effort of making it so.
Scott
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
