Threads and static initialization.

[Michel Fortin]

On 2010-12-17 19:15:07 -0500, Jonathan M Davis <jmdavisProg at gmx.com> said:

> On Friday 17 December 2010 16:02:27 Michel Fortin wrote:
>> On 2010-12-17 16:47:05 -0500, wrzosk <dprogr at gmail.com> 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
michel.fortin at michelf.com
http://michelf.com/