Gregory Stark wrote:
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.
That's a whole different thing to saying that you can't use a threaded
subsystem under a Postgres
process.
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.
Is there any particular reason not to ensure that any low-level
threading support in libc is enabled right
from the get-go, as a build-time option? Does it do anything that's not
well defined in a threaded
process? Signal handling and atfork (and posix_ exec) are tyical areas
I guess. While this can potentially
make malloc slower, Postgres already wraps malloc so using a caching
thread-aware malloc
substitute such as nedmalloc should be no problem.
I don't see any issue with the setjmp usage - so long as only one thread
uses any internal API. Which
can be checked rather easily at runtime with low cost in a debug build.
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.
Is that really much of an issue an the current version of any major OS
though? Its reaonable to
limit the use of a threaded library (in particular, the runtimes for
most embeddable languages, or
libraries for RPC runtimes, etc) to 'modern' platforms that support
threads effectively. On
many such platforms these will already implicitly link libpthread anyway.
James
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
