>
> On Tue, 5 Feb 2002, Haroldo Stenger wrote:
>
> > Just a question, in order to elighten my thought. Does the current experimental
> > threaded server disable multi-process model? Or does it *add* the functionality
> > as a compile switch? (This would be the other way round as the one you pointed
> > out.)
> >
Currently, exper. threaded postgres can have multiple processes using
multiple threads with the same shared memory. There is no forking
involved in the process though. Shared memory, mutexes, and conditonal
locks go global or private to the process based on a run-time flag.
>
> That's kinda what I was hoping ... is it something that could be
> seamlessly integrated to have minimal impact on the code itself ... even
> if there was some way of having a 'thread.c' vs 'non-thread.c' that could
> be link'd in, with wrapper functions?
>
The first basic problem is that global variables are scattered throughout
the source as well as some static stack variables. Hunting these down and
finding a home for them is, in and of itself, a major task. For example,
flex
produces code that is not thread safe, you have to modify that too. The
current work around in exper. thrreaded postgres is not pretty, one
"environment" structure that holds all the normal postgres globals in
thread local storage. This makes compile time choices impractical I
think.
Cheers,
Myron
mkscott@sacadia.com