On Wed, 6 Feb 2002, Marc G. Fournier wrote:
> Are there code clean-ups that have gone into the thread'd code that could
> be incorporated into the existing code base that would start us down that
> path?
I don't think existing code is much help. So much has changed since 7.0.2
that the current threaded code is propbably only good for investigating
the benefits of threading and maybe some porting techniques.
> For instance, based my limited understanding of threaded servers, I
> believe that 'global variables' are generally considered "A Real Bad
> Thing" ... in one of your email's, you mentioned:
>
> "The first basic problem is that global variables are scattered throughout
> the source ..."
>
> Now, what is a 'clean' solution to this?
The current threaded postgres is messy because I just packed all the
global variables, including those produced be flex, into a 5K structure.
Everytime threaded code needed a "global", it called a function to
retrieve a pointer from thread local storage. When I profiled the code I
saw way too many calls to grab the environment structure and I modified
some hotspots to pass the structure down the call chain. Ideally, I think
that the "environment" structure could be optimized for size and passed
down the call chain to reduce the number of times thread local storage is
accessed. This is also bad because when anyone working on a segment of
code needs a global, they need to add it to the "environment" structure.
I don't think this would be a good situation for code maintainers.
>
> Someone, or a group of ppl, with thread knowledge needs to start this
> forward ... once the clean up begins, even without any thread code thrown
> in, it shouldn't be too difficult to keep it clean to go to 'the next
> step', no?
>
I came up with a process to find global variables in the code that became
somewhat effective and could be applied to the current code. Someone else
might have a better way of ding this though.
Myron
mkscott@sacadia.com
