On Sat, Jan 06, 2007 at 12:01:46PM -0000, Eric Berend wrote:
> This one problem has completely impeded adoption of OCaml as the
> development language of choice for this project. Much as I have often
>; loathed the actions of Microsoft in our industry, their "F#" variant
> *does* allow re-entrant code. What are the designers and development
> personnel at INRIA involved in the OCaml project, doing to address
> this issue? Ours cannot be the only endeavor with such considerations.
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.
So what can you do? Here are some approaches you may consider:
(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.
(1a) Use threads - C threads _can_ run in parallel with OCaml threads.
(2) Use OCamlMPI. The advantage here is that your program will scale
far beyond SMP, and because it doesn't require mutexes, locks, shared
memory and so on, it'll be a lot easier to debug.
(3) Fork. For servers, assuming a sane Unix-like OS, forking is often
a great way to get parallelism, if your processes don't need to
communicate much.
(4) Use something like the 'Ancient' module
(http://merjis.com/developers/ancient) with separate processes -- only
works if your shared data is read only and can be constructed in
advance.
(5) Use F#
(6) Write single-threaded code.
(7) Develop the required changes to OCaml or bribe INRIA with such a
lot of money they swallow their principles.
(8) Use another language.
Rich.
--
Richard Jones
Red Hat UK Limited
.