From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8F14EBC6B for ; Thu, 11 Oct 2007 15:47:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAG7GDUfLENaMn2dsb2JhbACOSgEBAQEHBAYJIA X-IronPort-AV: E=Sophos;i="4.21,260,1188770400"; d="scan'208";a="17845665" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Oct 2007 15:47:22 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIPFDUd5LCRs/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,260,1188743400"; d="scan'208";a="208449332" Received: from ppp121-44-36-108.lns10.syd7.internode.on.net (HELO [192.168.1.201]) ([121.44.36.108]) by ipmail01.adl2.internode.on.net with ESMTP; 11 Oct 2007 23:17:15 +0930 Subject: Re: [Caml-list] Functional design for a basic simulation pipe. From: skaller To: Hugo Ferreira Cc: caml-list@yquem.inria.fr, Raj Bandyopadhyay In-Reply-To: <470DF2F1.4020204@inescporto.pt> References: <470C8199.4080708@inescporto.pt> <1192005274.6285.4.camel@rosella.wigram> <470CA488.1070804@inescporto.pt> <1192028408.6198.31.camel@rosella.wigram> <1192031761.6728.31.camel@rosella.wigram> <470DC95D.8020701@inescporto.pt> <1192090171.16809.82.camel@rosella.wigram> <470DF2F1.4020204@inescporto.pt> Content-Type: text/plain Date: Thu, 11 Oct 2007 23:47:14 +1000 Message-Id: <1192110434.6045.5.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; 0100,:01 parallelism:01 threads:01 threads:01 sourceforge:01 wrote:01 wrote:01 caml-list:01 primitives:01 inefficient:02 functional:02 pthreads:02 pthreads:02 module:03 guess:04 On Thu, 2007-10-11 at 10:54 +0100, Hugo Ferreira wrote: > skaller wrote: > > The pthreads/Event module based approach is fully natural > > but doesn't scale because pthreads don't, and it is inefficient > > because it synchronises using primitives designed to support > > multi-processing when basic circuits do not need any > > parallelism. > > > > Actually if I am not mistaken the example I refer to was using > pthreads. When I read your code I assumed they were the equivalent of > pthreads or some lighter version (user land, green threads). I guess > this is not so. Yes they're user land (green) threads, cooperative multi-tasking, fibres, or whatever you want to call them. -- John Skaller Felix, successor to C++: http://felix.sf.net