On Thu, 20 Feb 2003, Michel Schinz wrote:

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

I agree here, but...

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

Each kernel level thread has overhead.  On Linux, it's like 8K.  So the 
difference between spawning one thread or two is irrelevent- but the 
difference between spawning one thread and two thousand is important.

Also, you have a dispatching problem.  What the OS hands to the 
application is a message like "the mouse clicked at location (x, y)".  The 
application then needs to figure out that location (x, y) just happens to 
be in the OK button, and call the correct callback.

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

Again, select has uses- especially if there is going to be a lot of time 
between events.  As an example, take a look at inetd.

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

Threads are most definately usefull- but so is select and event dispatch 
loops, in their place.  Use the right tool for the job.

Brian


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