On Tue, Nov 30, 2010 at 4:29 PM,
<oliver@first.in-berlin.de> wrote:
And here I see a thread-specific GC as a solution.
It seems to me that this way was not thought about before,
and people thought about changing the GC to be able to handle multiple threads.
Instead I mean: each thread that is not the global thread, get's it's own
thread-specific GC.
Maybe that can be implemented much easier.
But I've not looked into the Ocaml internals to say: yes, this can be done
comparingly easy, or to say: oh no, that's more complex than changing the GC and make it
handle all the threads from the main thread.
I just would assume that seperate threads would be easier to handle.
But maybe there are other restrictions in the language or the compiler
that block this attempt.
Not anything that I have yet found but I am curious about the opinion of the runtime designers as well. There seem to be some global variables in the runtime, which isn't the best way to write it anyway, if all vars are local then it becomes easier to embed, thread and fork as you like. That is to say, such a level of virtualization allows the global lock to be substituted with whatever locking the system alloc functions have, i.e. when many malloc requests overlap.
Except that, the user has to explicitly sync his mem accesses so I don't think there could be any problem. And no other part of the library is thread-safe either (which is great for performance!). So I think each thread can have its own GC. Perhaps there is an obstacle I have not yet noticed?
Best,