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