| Copyright | (c) The University of Glasgow 2001 |
|---|---|
| License | BSD-style (see the file libraries/base/LICENSE) |
| Maintainer | libraries@haskell.org |
| Stability | experimental |
| Portability | non-portable |
| Safe Haskell | Trustworthy |
| Language | Haskell2010 |
System.Mem.Weak
Description
In general terms, a weak pointer is a reference to an object that is not followed by the garbage collector - that is, the existence of a weak pointer to an object has no effect on the lifetime of that object. A weak pointer can be de-referenced to find out whether the object it refers to is still alive or not, and if so to return the object itself.
Weak pointers are particularly useful for caches and memo tables. To build a memo table, you build a data structure mapping from the function argument (the key) to its result (the value). When you apply the function to a new argument you first check whether the key/value pair is already in the memo table. The key point is that the memo table itself should not keep the key and value alive. So the table should contain a weak pointer to the key, not an ordinary pointer. The pointer to the value must not be weak, because the only reference to the value might indeed be from the memo table.
So it looks as if the memo table will keep all its values alive for ever. One way to solve this is to purge the table occasionally, by deleting entries whose keys have died.
The weak pointers in this library support another approach, called finalization. When the key referred to by a weak pointer dies, the storage manager arranges to run a programmer-specified finalizer. In the case of memo tables, for example, the finalizer could remove the key/value pair from the memo table.
Another difficulty with the memo table is that the value of a key/value pair might itself contain a pointer to the key. So the memo table keeps the value alive, which keeps the key alive, even though there may be no other references to the key so both should die. The weak pointers in this library provide a slight generalisation of the basic weak-pointer idea, in which each weak pointer actually contains both a key and a value.
The Weak type
A weak pointer object with a key and a value. The value has type v.
A weak pointer expresses a relationship between two objects, the key and the value: if the key is considered to be alive by the garbage collector, then the value is also alive. A reference from the value to the key does not keep the key alive.
A weak pointer may also have a finalizer of type IO (); if it does,
then the finalizer will be run at most once, at a time after the key
has become unreachable by the program ("dead"). The storage manager
attempts to run the finalizer(s) for an object soon after the object
dies, but promptness is not guaranteed.
It is not guaranteed that a finalizer will eventually run, and no attempt is made to run outstanding finalizers when the program exits. Therefore finalizers should not be relied on to clean up resources - other methods (eg. exception handlers) should be employed, possibly in addition to finalizers.
References from the finalizer to the key are treated in the same way as references from the value to the key: they do not keep the key alive. A finalizer may therefore ressurrect the key, perhaps by storing it in the same data structure.
The finalizer, and the relationship between the key and the value,
exist regardless of whether the program keeps a reference to the
Weak object or not.
There may be multiple weak pointers with the same key. In this case, the finalizers for each of these weak pointers will all be run in some arbitrary order, or perhaps concurrently, when the key dies. If the programmer specifies a finalizer that assumes it has the only reference to an object (for example, a file that it wishes to close), then the programmer must ensure that there is only one such finalizer.
If there are no other threads to run, the runtime system will check for runnable finalizers before declaring the system to be deadlocked.
WARNING: weak pointers to ordinary non-primitive Haskell types are particularly fragile, because the compiler is free to optimise away or duplicate the underlying data structure. Therefore attempting to place a finalizer on an ordinary Haskell type may well result in the finalizer running earlier than you expected. This is not a problem for caches and memo tables where early finalization is benign.
Finalizers can be used reliably for types that are created explicitly
and have identity, such as IORef and MVar. However, to place a
finalizer on one of these types, you should use the specific operation
provided for that type, e.g. mkWeakIORef and addMVarFinalizer
respectively (the non-uniformity is accidental). These operations
attach the finalizer to the primitive object inside the box
(e.g. MutVar# in the case of IORef), because attaching the
finalizer to the box itself fails when the outer box is optimised away
by the compiler.
The general interface
Establishes a weak pointer to k, with value v and a finalizer.
This is the most general interface for building a weak pointer.
finalize :: Weak v -> IO () Source #
Causes a the finalizer associated with a weak pointer to be run immediately.
Specialised versions
mkWeakPtr :: k -> Maybe (IO ()) -> IO (Weak k) Source #
A specialised version of mkWeak, where the key and the value are
the same object:
mkWeakPtr key finalizer = mkWeak key key finalizer
addFinalizer :: key -> IO () -> IO () Source #
A specialised version of mkWeakPtr, where the Weak object
returned is simply thrown away (however the finalizer will be
remembered by the garbage collector, and will still be run
when the key becomes unreachable).
Note: adding a finalizer to a ForeignPtr using
addFinalizer won't work; use the specialised version
addForeignPtrFinalizer instead. For discussion
see the Weak type.
.
mkWeakPair :: k -> v -> Maybe (IO ()) -> IO (Weak (k, v)) Source #
A specialised version of mkWeak where the value is actually a pair
of the key and value passed to mkWeakPair:
mkWeakPair key val finalizer = mkWeak key (key,val) finalizer
The advantage of this is that the key can be retrieved by deRefWeak
in addition to the value.
A precise semantics
The above informal specification is fine for simple situations, but matters can get complicated. In particular, it needs to be clear exactly when a key dies, so that any weak pointers that refer to it can be finalized. Suppose, for example, the value of one weak pointer refers to the key of another...does that keep the key alive?
The behaviour is simply this:
- If a weak pointer (object) refers to an unreachable key, it may be finalized.
- Finalization means (a) arrange that subsequent calls
to
deRefWeakreturnNothing; and (b) run the finalizer.
This behaviour depends on what it means for a key to be reachable. Informally, something is reachable if it can be reached by following ordinary pointers from the root set, but not following weak pointers. We define reachability more precisely as follows.
A heap object is reachable if:
- It is a member of the root set.
- It is directly pointed to by a reachable object, other than a weak pointer object.
- It is a weak pointer object whose key is reachable.
- It is the value or finalizer of a weak pointer object whose key is reachable.
Implementation notes
A finalizer is not always called after its weak pointer's object becomes unreachable. There are two situations that can cause this:
- If the object becomes unreachable right before the program exits, then GC may not be performed. Finalizers run during GC, so finalizers associated with the object do not run if GC does not happen.
- If a finalizer throws an exception, subsequent finalizers that had been queued to run after it do not get run. This behavior may change in a future release. See issue 13167 on the issue tracker. Writing a finalizer that throws exceptions is discouraged.
Other than these two caveats, users can always expect that a finalizer will be run after its weak pointer's object becomes unreachable. However, the second caveat means that users need to trust that all of their transitive dependencies do not throw exceptions in finalizers, since any finalizers can end up queued together.