Re: Threaded PosgreSQL server
От | |
---|---|
Тема | Re: Threaded PosgreSQL server |
Дата | |
Msg-id | Pine.GSO.4.10.10202061835590.2566-100000@goldengate.kojoworldwide.com. обсуждение исходный текст |
Ответ на | Re: Threaded PosgreSQL server ("Marc G. Fournier" <scrappy@hub.org>) |
Ответы |
Re: Threaded PosgreSQL server
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: