On Mon, Apr 12, 2004 at 07:37:09PM -0500, Brian Hurt wrote:
> The threading is all user-space threading.  It doesn't take advantage of 
> multiple CPUs, doesn't use system threads, if one thread blocks they all 
> block, etc.

Which explains the existance of the separate Unix library for
threadying; I'm assuming that this library uses non-blocking fd's...

> There are two problems with multithreading.  First, it makes the GC more
> difficult and more costly.  Currently, the GC runs in the same system
> thread as everything else, and thus it doesn't have synchronization
> issues.  In a multi-threaded environment, you have synchronization issues
> which slows things down.  Second, most people don't know how to write
> safe, correct, efficient multithreaded programs.  It's harder than it
> looks.  I think something like MPI between seperate processes would be a 
> better way to take advantage of multi-processors.

I know little about the GC issue, save that two other garbage-collected
languages I have used (Java and Python) are able to work around it.

Python does have a global interpreter lock that protects sections of
Python code in certain situations, I believe.  However, Python uses true
threads, so it is fine to call blocking system calls in threads (it will
not block the entire program).

You are correct that there are gotchas with multithreaded programming.
However, there are some significant advantages.  One is that there is no
need to establish lines of communication between one process and
another -- that saves a significant amount of work right there.  It's
also pretty easy in most systems to fire up a thread to run a function
and check for (or be notified about) its result later.

OCaml's design, minimizing the need to update variables, seems to lend
itself nicely towards threadsafe programming.

I think that, overall, the fact that "some people can't do x correctly"
is not a reason to make x unsupported in a language.  After all, we've
seen programs all over that have buggy calls to open(2) -- especially
those writing in /tmp.  That doesn't mean we have to turn off open(2) on
our systems :-)

The alternatives are not necessarily easier anyway.  Forking and
communicating over pipes involves the development of a streaming
protocol and a way to send data across the pipe and decode it at the
other end; existing objects cannot just be reused.  Synchronization can
still be an issue, especially regarding open file descriptors, user
interfaces, and disk files.  Deadlock can occur on pipes due to any
number of reasons as well.

> On Unix, you don't lose much doing multi-proccess (forks) instead of
> threads.  Switching between processes in Unix isn't any slower than
> switching between threads within a process.  But I've seen benchmarks

My primary concern here lies not with the performance difference between
forking and threads in the general case, but rather the design
differences.  For certain tasks, threading is just easier.  And it looks
like OCaml has some serious limitations on threading.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners