On 2010-12-17 19:15:07 -0500, Jonathan M Davis <[email protected]> said:
On Friday 17 December 2010 16:02:27 Michel Fortin wrote:
On 2010-12-17 16:47:05 -0500, wrzosk <[email protected]> said:
I believe that when new thread is being created, all static data is
initialized inside new thread. What worries me is the fact, that many
'mini' threads will initialize all static data inside application. This
may be somewhat time consuming.
Maybe there should be a possibility to define 'Pure' thread that doesnt
touch any static data, and in turn it could leave static constructors
untouched.
What do you think
You mean something like this:
pure void doSomething(Tid parent) {
int result = 1 + 1;
parent.sendMessage(result);
}
void main() {
spawn(&doSomething);
... wait for message ...
}
Perhaps 'spawn' could do this when you feed it with a pure function.
That would only work if send() can be pure, and I really doubt that it can be.
If it _can_, then that might be a good optimization, but I'm betting that it
can't be done. Someone more familiar with how send() work would have to say on
that though, since I'm not intimately familiar with how send() works.
That's an interesting question.
There isn't much difference between sendMessage and appending a value
to an array. A pure function can append things to a mutable array it
gets as a parameter, so why couldn't it append to another thread's
message queue it gets as a parameter?
Your question is probably more about wether manipulating
synchronization primitives should be pure or not. Things like locking a
mutex or waiting on a condition. I don't see why they should not.
Consider a strongly pure function that creates its own synchronization
primitive for internal usage; how is that going to affect the rest of
the program considering that no other parts of the program has access
the same instances of those primitives?
--
Michel Fortin
[email protected]
http://michelf.com/
