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 p19NokfK015225 for ; Thu, 10 Feb 2011 00:50:46 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcBAD+3Uk3RVaE2imdsb2JhbACXSI4VCBUBAQEKCQwHDwYgoV2KDIIYhF0viFkBAQMFhVcEhH+GcYg2Og X-IronPort-AV: E=Sophos;i="4.60,448,1291590000"; d="scan'208";a="75659459" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Feb 2011 00:50:41 +0100 Received: by fxm16 with SMTP id 16so835177fxm.27 for ; Wed, 09 Feb 2011 15:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=Q9PXTU25ZL33AKVYsBV2EG/xkHxzB4sjFlrzw5bVn4I=; b=T6sfu7U2G6ZopL2xJHAk6In3YsnPe0WMWv2KaOKY7Eo70ZnaTQ2gdUqiYqSeD/2lgR NjX0qMLB4IxLu2bJ6vT/rBLchD159fEfpka6Y0zj6Lj9a2Njm8Tdr6yNkjJfzTJEqpuF /aGSoyDP+QRyVpxUYp7y0YRHVc/XCtiBu4lq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=ShEpaRN1uMRJMHX7zknWhXYy4IOKjY6M4qr9ygS1cVW+0s00Ey3b5b2Fl56LJwWVMb fKDVgMn2V28NTt2mzn5piBN9jx+OmEY+lCVI3QWX/eisGdYmdrKE5IdXcdgBvcjhGIwF GioMxIxrn2G75xEkkuDfzk6/dIrNs4NusxuOw= Received: by 10.223.111.137 with SMTP id s9mr2193834fap.98.1297295440413; Wed, 09 Feb 2011 15:50:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.97.67 with HTTP; Wed, 9 Feb 2011 15:50:20 -0800 (PST) In-Reply-To: References: From: Raoul Duke Date: Wed, 9 Feb 2011 15:50:20 -0800 Message-ID: To: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p19NokfK015225 Subject: Re: [Caml-list] Structural avoidance of memory leaks? On Wed, Feb 9, 2011 at 12:47 AM, David MENTRE wrote: >  * Tells me, as a practitioner, how to *structurally* avoid those > memory leaks? For example by avoiding some data structures or certain > kind of expressions. purity? i mean, avoid shared state, and of course shared mutable state.