Bruce Momjian wrote:
> 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
