Claudio Natoli <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
