From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2PANMXQ007263 for ; Fri, 25 Mar 2011 11:23:22 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUDACVsjE3RVaE2kGdsb2JhbACERKEGCBQBAQIJCQ0HFAQhiE2gE4oYgl2FKokLAQEDBYRtdwSMdYNUc4RCOoEd X-IronPort-AV: E=Sophos;i="4.63,242,1299452400"; d="vcf'?scan'208";a="79051785" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Mar 2011 11:23:15 +0100 Received: by fxm11 with SMTP id 11so1568133fxm.27 for ; Fri, 25 Mar 2011 03:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Kz3kekG0ZSReuGCq1zimMHdKHzRs3LjWvlSgrM9lcuQ=; b=QZvW3MFRUkiIGi9JAubHpFHOgqnjuH1d0ntmuu369cNEaImDd4kJ+57pNKhELZXLEP OB8h53NWMyKNmSSCWWrkkm6uhABMy2SS1K0LKLoAQhZI3gaexep7DLLc1LFD0eOXomkN anD3gJe6LmlOxQSYh20Gran4jIbto6LT3rFMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=j3/2r1s6pc/6WnovRVOSWLLTKD76cc7W90T8lWvbIucuMBWQhuB8lN2x8NKs53+5nn //Dt3Iy1VbXylYWt+o2MUZDAZnm7MQk8mG19AnyNzz3FaUfm72OWo3rtKxyJNM0Dn4Cz CEFeLOj/W1WgPWrgIUgL5dD5fsx5xuXAyZClI= Received: by 10.223.60.81 with SMTP id o17mr678963fah.48.1301048595414; Fri, 25 Mar 2011 03:23:15 -0700 (PDT) Received: from [195.83.212.218] (chercheurs-218.saclay.inria.fr [195.83.212.218]) by mx.google.com with ESMTPS id l2sm338502fam.5.2011.03.25.03.23.13 (version=SSLv3 cipher=OTHER); Fri, 25 Mar 2011 03:23:14 -0700 (PDT) Sender: Fabrice Le Fessant Message-ID: <4D8C6D10.2020205@inria.fr> Date: Fri, 25 Mar 2011 11:23:12 +0100 From: Fabrice Le Fessant User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Alain Frisch CC: caml-list@inria.fr References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> <1396338209.232813.1301046980856.JavaMail.root@zmbs4.inria.fr> In-Reply-To: <1396338209.232813.1301046980856.JavaMail.root@zmbs4.inria.fr> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------060000050607050800090106" Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? This is a multi-part message in MIME format. --------------060000050607050800090106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Alain, > What are the advantages of this approach over multi-processing (+ > explicit shared memory)? Multi-processing brings extra isolation and > safety; and it requires no change to the runtime system or the FFI. Multi-processing has several drawbacks: you have to either create several binaries for different tasks (master and workers usually), or use options for that; you have to define a way to setup the system, for example the master has to launch the workers, and for that, you have to know where binaries are installed. On the contrary, with the "ocaml fork" approach, you just have one program executing, so you can assume a smaller knowledge of the environment. For the FFI, I think it is actually possible to keep some backward-compatibility, by allowing both a new kind of external C functions (taking a thread specific context as argument, and declared with the "reentrant" flag introduced by Sylvain) and the former kind (without the context). Each function of the runtime would come in both kinds, for example "caml_alloc_r" taking the context as extra argument, and "caml_alloc" without the context, the latter being a wrapper for the former, with a way to recover the context in the middle (either through TLS or thread specific). Most stub libraries would probably work without change, maybe with a little extra-cost (actually, I think TLS is costless, and thread specific is very efficient on Mac OS X where TLS does not exist). > One advantage of the approach you describe is that it would allow to use > native libraries that support multi-threading. Do you see other advantages? As I said before, the main one for me is the ability to setup everything in one process, you can for example create locks, shared segments and other synchronisation primitives in the main thread, before creating the other threads, which is a little more difficult with multi-processing. Cheers, -- Fabrice --------------060000050607050800090106 Content-Type: text/x-vcard; charset=utf-8; name="fabrice_le_fessant.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fabrice_le_fessant.vcf" begin:vcard fn:Fabrice LE FESSANT n:LE FESSANT;Fabrice org:INRIA Saclay -- Ile-de-France;Projet OCamlPro adr;quoted-printable:;;Parc Orsay Universit=C3=A9 ;Orsay CEDEX;;91893;France email;internet:fabrice.le_fessant@inria.fr title;quoted-printable:Charg=C3=A9 de Recherche tel;work:+33 1 74 85 42 14 tel;fax:+33 1 74 85 42 49 url:http://fabrice.lefessant.net/ version:2.1 end:vcard --------------060000050607050800090106--