Re: Multi-threading friendliness

Craig James wrote:
> Don't confuse thread-friendly with a threaded implemetation of 
> Postgres itself.  These are two separate questions.  Thread-friendly 
> involves compile/link options that don't affect the Postgres source 
> code at all.
Indeed.  I'm specifically not suggesting that Postgres should offer an 
API that can be called from
anything except the initial thread of its process - just that library 
subsystems might want to use
threads internally and that should be OK. Or rather, it should be 
possible to build Postgres
so that its OK.  Even if there's a small slowdown, the benefit of 
running the full JVM or CLR
might outweigh that quite easily *in some circumstances*.

I've also hinted that at some stage you might want to thread some parts 
of the implementation,
but I'm not suggesting that would be an early target.  It seems to me 
sensible to make it
straightforward to take baby steps in that direction in future would be 
a reasonable thing to
do.  As would being friendly to dynamically loaded C++ code.  If you 
create the framework,
(and we're talking the barest of scaffolding) then others can work to 
show the cost/benefit.

I fail to see why this would be a controversial engineering approach.

James