From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA07003; Thu, 20 Feb 2003 17:16:41 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA06985 for ; Thu, 20 Feb 2003 17:16:40 +0100 (MET) Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1KGGdH11762 for ; Thu, 20 Feb 2003 17:16:39 +0100 (MET) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Feb 2003 10:15:19 -0600 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Feb 2003 10:15:19 -0600 Date: Thu, 20 Feb 2003 10:26:32 -0600 (CST) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Michel Schinz cc: Subject: Re: [Caml-list] Re: feature priorities (multithreading) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 20 Feb 2003 16:15:19.0377 (UTC) FILETIME=[43170C10:01C2D8FB] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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