From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA14774 for caml-redistribution; Tue, 18 Mar 1997 15:07:03 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA10406 for <caml-list@pauillac.inria.fr>; Tue, 18 Mar 1997 11:09:45 +0100 (MET)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2]) by concorde.inria.fr (8.7.6/8.7.3) with ESMTP id LAA13731 for <caml-list@pauillac.inria.fr>; Tue, 18 Mar 1997 11:09:43 +0100 (MET)
Received: from betze.bbn.hp.com by hplb.hpl.hp.com; Tue, 18 Mar 1997 10:09:41 GMT
Received: from localhost (localhost [127.0.0.1]) by betze.bbn.hp.com with SMTP (8.7.1/8.7.1) id LAA23108 for <caml-list@pauillac.inria.fr>; Tue, 18 Mar 1997 11:09:39 +0100 (MET)
Message-Id: <199703181009.LAA23108@betze.bbn.hp.com>
X-Authentication-Warning: betze.bbn.hp.com: Host localhost [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 1.6.4 10/10/95
To: caml-list@pauillac.inria.fr
Subject: Re: Weak pointers 
In-Reply-To: Damien.Doligez's message of Mon, 17 Mar 1997 20:19:00 +0100.
      <199703171919.UAA04633@tobago.inria.fr> 
X-Face: 7'_lwZ-\~X.Q]-O#D;ju@c|HTi9[>\U8jV5(8sQpm)twOCgN.y]9s:L}A1_]h}_LHF@U5!2
	5~FJ"9)`@~BEg9d;ftlb:bj9N>RTv0[VvZe7EMMB:$9hUc]&d9VN?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Mar 1997 10:09:38 +0000
From: Kohler Markus <kohlerm@betze.bbn.hp.com>
Sender: weis

[...]
 
> >  Could someone post an example of their use?
> 
> You can use them to implement hash-consing.  Assume you have some tree
> data structure.  If you want to share the nodes wherever possible, you
> can put every created node into a hash table.  Then when you are about
> to create a new node, you first look in the hash table to see if the
> same node has already been created.  If this is the case, you return
> the old one from the hash table instead of creating a new one.
> 
> But the above prevents the GC from collecting the nodes when they
> become unused, because they will always be reachable from the hash
> table.  If you use weak pointers in your hash table, the GC will be
> able to deallocate the dead nodes, but you still can have access to
> the live ones through the weak pointers.
> 

I'm not sure if it makes sense to implement such a tree with weak pointers. 
To be honest, I think it's not a good idea to do so. 

The problem is that if you delete an element in the tree it may be that the 
hash table still points to the node, because there was no garbage collection 
yet. It could be possible that you would still find the entry trough the hash 
table.

IMHO the real solution is to implement a delete method for the tree whcih 
takes care of all that internal pointers. 

By the way, I know what I'm speaking about because we have here an application 
using the same idea to implement some kind of cache. I does not work properly 
because nobody knows at which point of time the garbage collector throws way 
the objects. 

Regards,
Markus
 

-- 
+----------------------------------------------------------------------------+
| Markus Kohler                          Hewlett-Packard GmbH                |
| Software Engineer                      Network & System Management Division| 
|                                        IT/E Success Team                   |
+----------------------------------------------------------------------------+