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