On Tue, 5 Feb 2002 mkscott@sacadia.com wrote:
> 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.
Okay, but this has been discussed in the past concerning threading ... the
first make work that would have to be done was 'cleaning the code' so that
it was thread-safe ...
Basically, if we were to look at moving *towards* a fork/thread model in
the future, what can we learn and incorporate from the work already being
done? How much of the work in the threaded server is cleaning up the code
to be thread-safe, that would benefit the base code itself and start us
down that path?
Right now, from everythign I've heard, making the code thread-safe is one
big onerous task ... but if we were to start incorporating changes from
the 'thread work' that is being done now, into the base server, and ppl
start thinking thread-safe when they are coding new stuff, over time, this
task becomes smaller ...
