cashin@cs.uga.edu writes:

[...]

> Personally, I try to avoid threads because they usually make my
> programs less portable and sometimes more complex.

[...]

> If the threads in a program only run on one processor, then all you
> have is the overhead.

I don't agree here, some programs are inherently multi-threaded.

Take GUIs for example. Most GUI toolkits today are based on an event
loop, which waits for events and dispatches them to various
call-backs. This event loop is nothing more than a poor-man's
scheduler. It is a poor solution to the problem, though, because this
scheduler is not preemptive, and this means that your call-backs have
to execute quickly for the application to be responsive. It also means
that if your "threads" have a state, this state must be saved
explicitly between calls.

All applications which use Posix's "select" function are also
screaming for threads. When you use "select", you wait for one of
several events to happen, and when one happens you typically dispatch
to one event handling function. This is, again, nothing but an ad-hoc
scheduler.

John Reppy's book "Concurrent Programming in ML" contains several
examples of the usefulness of threads.

Michel.
-------------------
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