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 TAA22211; Thu, 29 Jan 2004 19:25:42 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 TAA22831 for ; Thu, 29 Jan 2004 19:25:41 +0100 (MET) Received: from mail4.tpgi.com.au (mail.tpgi.com.au [203.12.160.61]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i0TIPdP00261 for ; Thu, 29 Jan 2004 19:25:40 +0100 (MET) Received: from 203-219-225-179-syd-ts24-2600.tpgi.com.au (203-219-225-179-syd-ts24-2600.tpgi.com.au [203.219.225.179]) by mail4.tpgi.com.au (8.12.10/8.12.10) with ESMTP id i0TIPZD0006605; Fri, 30 Jan 2004 05:25:36 +1100 Subject: Re: [Caml-list] ocaml and concurrency From: skaller Reply-To: skaller@tpg.com.au To: james woodyatt Cc: The Trade In-Reply-To: <97908806-5238-11D8-8975-000393B8133A@wetware.com> References: <20040127063230.GA12482@inv_machine> <200401282326.i0SNQntl004612@bismarck-chet.watson.ibm.com> <97908806-5238-11D8-8975-000393B8133A@wetware.com> Content-Type: text/plain Message-Id: <1075400806.3632.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 30 Jan 2004 05:26:46 +1100 Content-Transfer-Encoding: 7bit X-TPG-Antivirus: Passed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 tpg:99 2004:99 woodyatt:01 chet:01 murthy:01 threads:01 higher-order:01 non-blocking:01 passing:01 monolithic:01 'need':99 c's:01 threads:01 tpg:99 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2004-01-29 at 19:53, james woodyatt wrote: > On 28 Jan 2004, at 15:26, Chet Murthy wrote: > But to write concurrent services without threads, you have to use a lot > of higher-order functions and non-blocking I/O functions. Hey, guess > what? Ocaml is a pretty good language for mixing functional > programming with imperative programming. What if the *right* way to > get concurrency really *is* the ancient Unix dogma of 1) use > heavyweight process switching and message passing between processes, > and 2) use monolithic event loops inside lightweight programs? See Felix. A large amount of 'need' for concurrency is actually a need for control inversion. Event driven programs are efficient but almost impossible to structure correctly: this is because a lot of state in block structured code is maintained on the stack and identified by the current value of the program counter: when you're programming directly with an event loop, you have to maintain all that state manually. In Felix, the programmer writes 'threads' and calls the 'read' primitive to get the next message. This is no different to calling C's 'read' function to read from a file, except the context switching is done in user space. The architecture would usually be several threads or processes to load the message queue, and a a small number of independent worker threads (typically one per CPU) to deliver the messages to the client threads synchronously. [The worker threads are event loops ..] I personally believe this architecture is useful in a wide class of applications, for example almost all kinds of servers. However, asynchronous (pre-emptive) context switching with shared data is certainly needed in many situations where neither cooperative multi-tasking nor processes are suitable.. .. for example even in the above architecture, threads are useful for loading the central message queue, even if all they're doing is synchronising with the processes actually procuring the messages. -- John Max Skaller, mailto:skaller@tpg.com.au snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net ------------------- 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