From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 88E3BBC57 for ; Tue, 30 Nov 2010 22:28:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAKb79ExKfVK2kGdsb2JhbACjBggVAQEBAQkJDAcRAx+pZIlkghiFJy6IVgEBAwWFQgSOWQ X-IronPort-AV: E=Sophos;i="4.59,281,1288566000"; d="asc'?scan'208";a="82022281" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Nov 2010 22:28:57 +0100 Received: by mail-wy0-f182.google.com with SMTP id 19so21881765wyf.27 for ; Tue, 30 Nov 2010 13:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=5W+EauAie6gRKv1xOenln9mCPA68Kkcf6FsHIy/bSXM=; b=bzg8ZqA+Esh0HIAm+aPT66FVlgfKWDFEwmcIjiLSSEeHWHVONBOlKfW5uRSdg5nq1g VfTzlR0tDyEMnJ2k2CZMAS8sPKXd2eqp9OjbixXHlagQtZvuEIo/t8y1InD6xY3ohZb+ Zt2fKYrXj1dbFG+Ydo7n9M+dLNPDoTsUuEGcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=e5/nQIbgyd/LvTMQpMPv+4ssFHkhKNnh+yecyWnzUkb11i6QIsfWHv3ofveym1ZwE9 Hl21aYNLzPU/1S/AbppY+N5mBtnUZKffkEgs7u81kGrSMb5znFi16A/Zj9MpvsedIjLl C/UL6X0ywDLjbjQvft1sxDHyXR/GLcBMaZ2h0= Received: by 10.227.55.71 with SMTP id t7mr3968493wbg.157.1291152536811; Tue, 30 Nov 2010 13:28:56 -0800 (PST) Received: from macbookpro.local (bin73-1-78-240-16-62.fbx.proxad.net [78.240.16.62]) by mx.google.com with ESMTPS id q18sm4494959wbe.17.2010.11.30.13.28.53 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Nov 2010 13:28:54 -0800 (PST) Message-ID: <4CF56C8F.8090400@univ-savoie.fr> Date: Tue, 30 Nov 2010 22:28:47 +0100 From: Christophe Raffalli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jon Harrop , OCaml Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?) References: <4CF4B17C.7000703@planet.nl> <20101130125545.GE1637@siouxsie> <0a7c01cb90d3$6efe7460$4cfb5d20$@com> In-Reply-To: <0a7c01cb90d3$6efe7460$4cfb5d20$@com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig191536275590F8192D7F11F8" X-Spam: no; 0.00; christophe:01 raffalli:01 threading:01 ocaml:01 pointer:01 pointer:01 ocaml:01 syntax:01 pointers:01 runtime:01 cheers:01 christophe:01 threads:01 compile:01 exception:01 X-Attachments: type="application/pgp-signature" name="signature.asc" name="signature.asc" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig191536275590F8192D7F11F8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 30/11/10 22:13, Jon Harrop a =E9crit : > What would be responsible for collecting the shared heap? Reference counting: if there are no pointer within the shared heap (I mean pointer to and from the shared heap), this should be quite easy via a finaliser .= =2E. For more than that, reference counting via finaliser + a real GC for the shared heap itself, because this heap being seen as a C region from OCaml, but using the memory representation of OCaml, it could be managed by your own GC. So globally, I think writing a C program that would manage an OCaml shared heap with its own GC and reference counting for the number of pointer from OCaml threads is quite feasible ... There remain the following problem of - an unexpectidely dying OCaml thread would leave its refenrece counting increased forever ... It is not clear we have to deal with that ... - What syntax to allocate in the Shared heap (some camlpN (N =3D 4 or 5) magic ?) - There is something to do for pointers from the shared heap to some OCaml heap, they have to be forbidden, but maybe you would like to disallow their apparition at compile time by some static analysis ... Anyway, they will be detected at runtime by page violation when an OCaml thread tries to follow a pointer to the heap of another thread. At least this page violation should be transformed into an OCaml exception. They will also be detected by the GC of the Shared heap ... An here it is not clear what to do ... Just ignore them ? Cheers, Christophe --------------enig191536275590F8192D7F11F8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz1bJMACgkQi9jr/RgYAS5UDACgqxiomH0McF6bJrrbWlUAmkIC NsoAn22z6Amv4JK2bun+1e6w/m2l6iRl =wbun -----END PGP SIGNATURE----- --------------enig191536275590F8192D7F11F8--