Richard Jones wrote:
>OCaml code can run in at most one thread at a time, and the reason for
>that is that the garbage collector isn't reentrant. If it was
>reentrant, it'd pay a considerable penalty. Until someone discovers a
>way to do parallel garbage collection for free, and a suitable way to
>write threaded code sensibly is also discovered (mutexes and shared
>memory is _not_ a sane way to write code), INRIA have made it quite
>;clear they're not interested.
Maybe I'm oversimplifying, but since the "-thread" option is already
needed to enable threaded code, couldn't there be a "-multithread"
option to enable a reentrant GC? That way single threaded code or
lightly threaded code could be written without the performance hit. I
would think that the performance hit of a parallel GC would be
overshadowed by the performance increase of actually using all of the
cores/processors if the code was written to take advantage of them.
>(1) Use threads where you don't need parallelism, eg. for making a
>responsive UI while doing light processing in another thread. The
>OCaml Event module (in stdlib) provides a fairly sensible
>message-passing environment.
The OCaml implementation of the Event module has a major fatal flaw:
threads are not GCed. If you read Reppy's book, one key feature of CML
and part of the programming paradigm it promotes is creating threads
that might block forever and are simply GCed when out of scope. This
is because CML threads are implemented using continuations. Because
OCaml uses POSIX threads, threads are not GCed and even simple programs
crash due to this. It is not even possible to add a workaround: if
Thread.kill actaully worked, one could add a finalizer to the thread
descriptor to achieve the same effect, but the implementation of the
Thread module is incomplete.
--Jonathan
.