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,DNS_FROM_SECURITYSAGE autolearn=disabled version=3.1.3 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 ACFE7BB84 for ; Fri, 31 Oct 2008 03:22:26 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAACAJCklCbwQbi2dsb2JhbACUDgEBAQoLCgcPBrc5g1E X-IronPort-AV: E=Sophos;i="4.33,519,1220220000"; d="scan'208";a="16696868" Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by mail2-smtp-roc.national.inria.fr with ESMTP; 31 Oct 2008 03:22:26 +0100 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id DB3E2189BD9; Thu, 30 Oct 2008 22:22:24 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Oct 2008 22:22:24 -0400 X-Sasl-enc: LDn6UcSVVocdgk7ff+q6mz7VO/mxODrHzP3QVdH4d+dQ 1225419744 Received: from [192.168.1.10] (ALyon-157-1-126-20.w90-42.abo.wanadoo.fr [90.42.21.20]) by mail.messagingengine.com (Postfix) with ESMTPSA id 22B9614C94; Thu, 30 Oct 2008 22:22:23 -0400 (EDT) Message-ID: <490A6A19.9050704@ens-lyon.org> Date: Fri, 31 Oct 2008 03:14:49 +0100 From: Martin Jambon User-Agent: Thunderbird 2.0.0.17 (X11/20081008) MIME-Version: 1.0 To: Warren Harris Cc: caml-list caml-list Subject: Re: [Caml-list] understanding weak References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ens-lyon:01 ocaml's:01 pointers:01 pointers:01 hash:01 pointer:01 pointer:01 hash:01 warren:98 wrote:01 caml-list:01 jambon:01 jambon:01 data:02 referenced:02 Warren Harris wrote: > I'd like to understand better how ocaml's weak pointers operate. First, > although it doesn't seem to be specified in the documentation, I assume > that weak pointers will *not* be reclaimed (e.g. from a weak hash table) > if the program retains some other reference to the object. I.e. the weak > pointer must be the last remaining pointer to the object for reclamation > to occur. Yes, otherwise the program would crash. > My second question relates specifically to my application. I would like > to have a primary cache of objects, and a secondary index into > sub-objects referenced from the primary cache. I.e. CacheA references > objects of type A; objects of type A reference objects of type B; CacheB > references objects of type B. I would like to guarantee that weak > references in CacheB are not flushed unless the corresponding reference > from CacheA is first flushed. I assume will be the case if a non-weak > reference from A to B is maintained. Can anyone verify? Weak pointers are useful for data that should be shared by several independent "users" and discarded when the number of users drops to zero. I wouldn't call your CacheB a cache if it is a weak array or a weak hash table. It is a table of shared objects. These objects of type B are shared by objects of type A and possibly other users of CacheB. Martin -- http://mjambon.com/