Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> 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