On Friday 17 December 2010 13:47:05 wrzosk wrote: > 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
That seems like it would be _really_ hard to do - probably impossible. The compiler would have to know which functions, types, and variables a thread accessed. I don't believe that compiler really knows anything about threads. It doesn't know which thread calls a particular function or accesses a particular variable. It knows about thread-local storage vs shared storage, and the type system restricts conversions between the two, but to do what you're suggesting, you'd have to have the compiler know which thread is calling which function and disallowing - at compile time - certain threads from calling certain functions. As it is, any thread can call anything and the compiler makes no attempt at tracking any of that. It just has restrictions with regards to thread-local and shared. So, while it certainly seems like a good idea, I don't see how it would really be possible. It might be possible to make it so that a thread could be created which did not initialize any module or static variables (be they at class, struct, or function scope), but I don't see how the compiler could enforce that none of those variables were used. It would have to be up to the programmer to only call pure functions. What _might_ be possible would be if you had a way of starting a thread which took a function (or overrode one) and that function _had_ to be strongly pure. Then it could skip running static constructors, because it would be impossible for any static variables to be accessed. However, the only way that you'd then get access to anything that thread did was from the return value of the function that started it, which not raises the issue of how you'd get the return value with the asynchronous nature of threads, but it would restrict the usage of such threads to the point that they'd be practically useless. I think that you raise a valid concern, but I don't think that that's the way to handle it. Restricting static constructors and global or static variables in practice will help, and using immutable more will help. But if we want a means of making threads more lightweight, we probably need to look at a different way of doing it than you're suggesting. This does make me wonder about static constructors and immutable though. It's currently possible to assign to both immutable and mutable module-scope variables in a static constructor. Such static constructors _must_ run for every thread or the thread-local portions are going to be wrong, but you _can't_ run them for immutable variables or you aren't sharing them between threads (or you're reassigning them each time that at new thread is created - I think that there's currently a bug on that). Perhaps static constructors which assign to immutable variables should have to be immutable, and mutable variables would have to be assigned in non-immutable static constructors. Then the immutable static constructors only get run once with the main thread, whereas the non- static ones get run for every thread. - Jonathan M Davis