Jose Alberto Fernandez wrote:
Peter,
The original reason for all the threadlocal stuff was to allow writing things like:
<parallel> <macro1 agr="1"/> <macro1 arg="2"/> </parallel>
Where "macro1" defines locals and in that case we do not want the
different threads to interfere with each other. Now does your changes
deal with this issue?
This works fine. The issue I was dealing with was existing local properties. The change made was that the stacks of localproperties are copied as before, but only the pointers to the properties are copied, and new properties are not created.
I had made copies for each thread. So each saw different properties. I had
done this originally because I was confused and was worried about
interthread race conditions on setting the existing local property, and about
the thread creator removing the local property while the thread is using it.
The cure was much worse that the problems, in that the local properties set
by the parallel tasks where not visible to the script that started up the <parallel>
task.
The whole point of my comments is that we cannot just take a blanket
policy
this way or that because it depends on the intensions of the user.
This is why I just provide new names, because our main problem is name
clashing
as we have a single flat namespace i.e., global-variables. And there is lots of code relying on this fact.
From the point of view of most languages, there is a flat namespace. For example in "C" one can do
int a;
void proc(void) {
int a;
a = 1;
}Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
