Skip site navigation (1) Skip section navigation (2)

Re: Mixing threaded and non-threaded

From: Scott Lamb <slamb(at)slamb(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Manfred Spraul <manfred(at)colorfullife(dot)com>,Steve Atkins <steve(at)blighty(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Mixing threaded and non-threaded
Date: 2004-01-30 19:57:52
Message-ID: 401AB740.70605@slamb.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Scott LambDate: 2004-01-30 20:08:52
Subject: Re: Mixing threaded and non-threaded
Previous:From: Andrew DunstanDate: 2004-01-30 19:06:05
Subject: Re: Why is it so easy to override -fno-strict-aliasing?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group