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 LAA30424; Thu, 20 Feb 2003 11:24:56 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA30409 for caml-list@pauillac.inria.fr; Thu, 20 Feb 2003 11:24:55 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA26374 for ; Thu, 20 Feb 2003 09:10:17 +0100 (MET) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1K8AGT09606 for ; Thu, 20 Feb 2003 09:10:16 +0100 (MET) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18llmR-0006fS-00 for ; Thu, 20 Feb 2003 09:10:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18lldB-0006EJ-00 for ; Thu, 20 Feb 2003 09:00:33 +0100 From: Michel Schinz Subject: [Caml-list] Re: feature priorities (multithreading) Date: Thu, 20 Feb 2003 09:00:36 +0100 Message-ID: References: <4.3.2.7.2.20030210183551.03118b08@localhost> <4.3.2.7.2.20030213083000.02fedc40@localhost> <87of5gp0ia.fsf_-_@uga.edu> <87fzqk5icy.fsf@uga.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i686-pc-linux-gnu) Cancel-Lock: sha1:lCQRNKkKIGc5ifqkAjzRc4sFLho= Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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