Re: Threads vs Processes

Поиск
Список
Период
Сортировка
Искать
От
Shridhar Daithankar
Тема
Re: Threads vs Processes
Дата
Msg-id
3F730817.9020402@persistent.co.in
Ответ на
Список
Дерево обсуждения
Re: Threads vs Processes (was: NuSphere and PostgreSQL for window Claudio Natoli <claudio.natoli@memetrics.com>
Re: Threads vs Processes (was: NuSphere and PostgreSQL for window s) Tom Lane <tgl@sss.pgh.pa.us>
Re: Threads vs Processes Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Threads vs Processes Tom Lane <tgl@sss.pgh.pa.us>
Re: Threads vs Processes Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Threads vs Processes Tom Lane <tgl@sss.pgh.pa.us>
Re: Threads vs Processes Bruce Momjian <pgman@candle.pha.pa.us>
Re: Threads vs Processes Tom Lane <tgl@sss.pgh.pa.us>
Re: Threads vs Processes Bruce Momjian <pgman@candle.pha.pa.us>
Re: Threads vs Processes Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Threads vs Processes Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Threads vs Processes Myron Scott <mkscott@sacadia.com>
Re: Threads vs Processes (was: NuSphere and PostgreSQL Manfred Spraul <manfred@colorfullife.com>
Tom Lane wrote:

> Claudio Natoli  writes:
> 
>>>How are you dealing with the issue of wanting some static variables to
>>>be per-thread and others not?
> 
> 
>>To be perfectly honest, I'm still trying to familiarize myself with the code
>>sufficiently well so that I can tell which variables need to be per-thread
>>and which are shared (and, in turn, which of these need to be protected from
>>concurrent access).
> 
> 
> Well, the first-order approximation would be to duplicate the current
> fork semantics: *all* static variables are per-thread, and should be
> copied from the parent thread at thread creation.  If there is some
> reasonably non-invasive way to do that, we'd have a long leg up on the
> problem.

Hmm.. I was looking for some fast tutorials on thread local storage. I found 
this one..
http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/thread_specific_data.htm

Basically, in a process we are free to declare as many globals as we can. 
Converting them to thread local is not an easy job because each variable would 
need it's own key and there is limit on how many keys can be allocated.

One thing that can be done is to arrange all globals/statics in a structure and 
make that structure thread local. We need to change all invocations of any of 
those variables to use a pointer. We just need only one global variable. And 
some macro trickery possibly so that we can extend that structure easily and 
automatically.

Upshot is duplicating environment is easy. We need to do a huge memcpy and any 
specific depp copy of strings on thread creation. Besides even in process model, 
  this kind of initialization will allow to put all variables on heap instead of 
stack. But then we need to add initialization code explicitly.

Something like int a=10; can not be added just like that.

If globals are less than 100 in numbers, I think it should be reasonably blind 
job of converting them to a structure type stuff. Don't know really though. My 
estimations are always 10% of what it takes..:-)

I hope I got it correct..

  Shridhar

В списке pgsql-hackers по дате отправления
От: Greg Stark
Дата:
От: Robert Treat
Дата:
FAQ