"Magnus Hagander" <magnus@hagander.net> writes:
> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>
>> This should be amended to say,
>>
>> "To be precise, a non-threaded, shared library needs to be created."
>
> Just before someone goes ahead and writes it (which is probably a good idea
> in general), don't write it just like taht - because it's platform
> dependent. On win32, you can certainly stick a threaded library to it -
> which is good, because most (if not all) win32 libs are threaded... Now, if
> they actually *use* threads explicitly things might break (but most likely
> not from that specifically), but you can link with them without the
> problem. I'm sure there are other platforms with similar situations.
Even on Unix there's nothing theoretically wrong with loading a shared library
which uses threads. It's just that there are a whole lot of practical problems
which can crop up.
1) No Postgres function is guaranteed to be thread-safe so you better protect
against concurrent calls to Postgres API functions. Also Postgres functions
use longjmp which can restore the stack pointer to a value which may have
been set earlier, possibly by another thread which wouldn't work.
So you're pretty much restricted to calling Postgres API functions from the
main stack which means from the original thread Postgres loaded you with.
Then there's
2) Some OSes have bugs (notably glibc for a specific narrow set of versions)
and don't expect to have standard library functions called before
pthread_init() then called again after pthread_init(). If they expect the
system to be either "threaded" or "not threaded" then they may be surprised
to see that state change.
That just means you have to use a non-buggy version of your OS. Unfortunately
tracking down bugs in your OS to figure out what's causing them and whether
it's a particular known bug can be kind of tricky.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
