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=1.0 required=5.0 tests=AWL,SPF_FAIL 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 18008BC6B for ; Thu, 20 Sep 2007 10:15:58 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB7J8UbAXQInlGdsb2JhbACOEQEBAQEHBAYH X-IronPort-AV: E=Sophos;i="4.20,277,1186351200"; d="scan'208";a="16460041" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 20 Sep 2007 10:17:19 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8K8GOtd008176 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 20 Sep 2007 10:16:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANPJ8UZQW+UCn2dsb2JhbACOEQEBAQEHBAYHIA X-IronPort-AV: E=Sophos;i="4.20,277,1186351200"; d="scan'208";a="2953676" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 Sep 2007 10:17:11 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IYHDd-0003AF-2e for caml-list@inria.fr; Thu, 20 Sep 2007 10:17:05 +0200 Received: from ivr94-8-88-162-26-239.fbx.proxad.net ([88.162.26.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Sep 2007 10:17:05 +0200 Received: from li by ivr94-8-88-162-26-239.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Sep 2007 10:17:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Zheng Li Subject: Re: [ANN] coThreads 0.10 Date: Thu, 20 Sep 2007 10:18:51 +0200 Message-ID: <87lkb1kavo.fsf@pps.jussieu.fr> References: <87lkb5fe3f.fsf@pps.jussieu.fr> <87sl5d8cgd.fsf@pps.jussieu.fr> <46F174D9.5060900@ujf-grenoble.fr> <877imm2z7h.fsf@pps.jussieu.fr> <1190249430.6642.1.camel@rosella.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ivr94-8-88-162-26-239.fbx.proxad.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:+sJ9rZBCPTP0+7Lyn4esYZCWaAk= Sender: news X-Miltered: at concorde with ID 46F22C58.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 speedup:01 makefile:01 makefile:01 0.10:98 threads:01 threads:01 sourceforge:01 sourceforge:01 naming:01 pps:01 pps:01 jussieu:01 jussieu:01 cma:01 Hi, First note that the naming convention follows the standard threads library in OCaml: Threads and coThreads (both with 's') refer to the library (*.cm(x)a); Thread and Cothread (neither with 's') are modules (*.cm[ox]) inside. skaller writes: >> The Thread module interfaces from the three engines differ with each >> other! Note that this is not the problem from coThreads, it's a problem of >> standard Threads library: > > Why don't you just use a different module name? The different module name *is* Cothread, a compatible super set of Thread module. Use this module instead if you want to have object-level compatibility. In short, all the three engines have the two libraries with isomorphic structures (quite simple) : threads.cm(x)a = threads.cm[ox], mutex.cm[ox], condition.cm[ox], event.cm[ox] cothreads.cm(x)a = threads.cm[ox], mutex.cm[ox], condition.cm[ox], event.cm[ox], cothread.cm[ox], stm.cm[ox] See, we also provide the compatible "threads.cm(x)a" for the process engine. Think about the following scenario: - If you're working on legacy code, you don't care STM and don't care object-level compatibility, the only thing you're interested is to running your code with process to speedup, then the only thing to change in your Makefile is the include path e.g. "-I +threads" -> "-I +process", you can still using Thread module and "threads.cma", they are present in process engine. - You have several projects, some of them using traditional Threads, some using coThreads, you don't want to bother to remember that. So simply changing all linking library from threads.cma to cothreads.cma is fine, because coThreads library contains every modules in Threads library. - You have some legacy code written in standard Threads, and you'd like to have it run with processes. Though you don't care about the newly introduced modules of coThreads, you do want to have a single copy of object files for each engines. In such case, you need to add one line to any source code which makes use of the Thread module: module Thread = Cothread because Thread module (the only module in Threads and coThreads) don't have object-level compatibility, and change any occurrence of “threads.cm(x)a” to “cothreads.cm(x)a” in your Makefile. For more explanation, see http://cothreads.sourceforge.net/doc/compatibility -- Zheng Li http://www.pps.jussieu.fr/~li