<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>System.Mem.Weak</title><link href="ocean.css" rel="stylesheet" type="text/css" title="Ocean" /><script src="haddock-util.js" type="text/javascript"></script><script type="text/javascript">//<![CDATA[
window.onload = function () {pageLoad();setSynopsis("mini_System-Mem-Weak.html");};
//]]>
</script></head><body><div id="package-header"><ul class="links" id="page-menu"><li><a href="index.html">Contents</a></li><li><a href="doc-index.html">Index</a></li></ul><p class="caption">base-4.5.1.0: Basic libraries</p></div><div id="content"><div id="module-header"><table class="info"><tr><th>Portability</th><td>non-portable</td></tr><tr><th>Stability</th><td>experimental</td></tr><tr><th>Maintainer</th><td>libraries@haskell.org</td></tr><tr><th>Safe Haskell</th><td>Trustworthy</td></tr></table><p class="caption">System.Mem.Weak</p></div><div id="table-of-contents"><p class="caption">Contents</p><ul><li><a href="#g:1">The <code>Weak</code> type
</a></li><li><a href="#g:2">The general interface
</a></li><li><a href="#g:3">Specialised versions
</a></li><li><a href="#g:4">A precise semantics
</a></li></ul></div><div id="description"><p class="caption">Description</p><div class="doc"><p>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.
</p><p>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.
</p><p>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.
</p><p>The weak pointers in this library
support another approach, called <em>finalization</em>.
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.
</p><p>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.
</p></div></div><div id="synopsis"><p id="control.syn" class="caption expander" onclick="toggleSection('syn')">Synopsis</p><ul id="section.syn" class="hide" onclick="toggleSection('syn')"><li class="src short"><span class="keyword">data</span> <a href="#t:Weak">Weak</a> v</li><li class="src short"><a href="#v:mkWeak">mkWeak</a> :: k -> v -> <a href="Data-Maybe.html#t:Maybe">Maybe</a> (<a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a>) -> <a href="System-IO.html#t:IO">IO</a> (<a href="System-Mem-Weak.html#t:Weak">Weak</a> v)</li><li class="src short"><a href="#v:deRefWeak">deRefWeak</a> :: <a href="System-Mem-Weak.html#t:Weak">Weak</a> v -> <a href="System-IO.html#t:IO">IO</a> (<a href="Data-Maybe.html#t:Maybe">Maybe</a> v)</li><li class="src short"><a href="#v:finalize">finalize</a> :: <a href="System-Mem-Weak.html#t:Weak">Weak</a> v -> <a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a></li><li class="src short"><a href="#v:mkWeakPtr">mkWeakPtr</a> :: k -> <a href="Data-Maybe.html#t:Maybe">Maybe</a> (<a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a>) -> <a href="System-IO.html#t:IO">IO</a> (<a href="System-Mem-Weak.html#t:Weak">Weak</a> k)</li><li class="src short"><a href="#v:addFinalizer">addFinalizer</a> :: key -> <a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a> -> <a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a></li><li class="src short"><a href="#v:mkWeakPair">mkWeakPair</a> :: k -> v -> <a href="Data-Maybe.html#t:Maybe">Maybe</a> (<a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a>) -> <a href="System-IO.html#t:IO">IO</a> (<a href="System-Mem-Weak.html#t:Weak">Weak</a> (k, v))</li></ul></div><div id="interface"><h1 id="g:1">The <code>Weak</code> type
</h1><div class="top"><p class="src"><span class="keyword">data</span> <a name="t:Weak" class="def">Weak</a> v </p><div class="doc"><p>A weak pointer object with a key and a value. The value has type <code>v</code>.
</p><p>A weak pointer expresses a relationship between two objects, the
<em>key</em> and the <em>value</em>: 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 <em>not</em> keep the key alive.
</p><p>A weak pointer may also have a finalizer of type <code>IO ()</code>; 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.
</p><p>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 finalisers.
</p><p>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.
</p><p>The finalizer, and the relationship between the key and the value,
exist regardless of whether the program keeps a reference to the
<code><a href="System-Mem-Weak.html#t:Weak">Weak</a></code> object or not.
</p><p>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.
</p><p>If there are no other threads to run, the runtime system will check
for runnable finalizers before declaring the system to be deadlocked.
</p></div><div class="subs instances"><p id="control.i:Weak" class="caption collapser" onclick="toggleSection('i:Weak')">Instances</p><div id="section.i:Weak" class="show"><table><tr><td class="src"><a href="Data-Typeable-Internal.html#t:Typeable1">Typeable1</a> <a href="System-Mem-Weak.html#t:Weak">Weak</a></td><td class="doc empty"> </td></tr></table></div></div></div><h1 id="g:2">The general interface
</h1><div class="top"><p class="src"><a name="v:mkWeak" class="def">mkWeak</a></p><div class="subs arguments"><p class="caption">Arguments</p><table><tr><td class="src">:: k</td><td class="doc"><p>key
</p></td></tr><tr><td class="src">-> v</td><td class="doc"><p>value
</p></td></tr><tr><td class="src">-> <a href="Data-Maybe.html#t:Maybe">Maybe</a> (<a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a>)</td><td class="doc"><p>finalizer
</p></td></tr><tr><td class="src">-> <a href="System-IO.html#t:IO">IO</a> (<a href="System-Mem-Weak.html#t:Weak">Weak</a> v)</td><td class="doc"><p>returns: a weak pointer object
</p></td></tr></table></div><div class="doc"><p>Establishes a weak pointer to <code>k</code>, with value <code>v</code> and a finalizer.
</p><p>This is the most general interface for building a weak pointer.
</p></div></div><div class="top"><p class="src"><a name="v:deRefWeak" class="def">deRefWeak</a> :: <a href="System-Mem-Weak.html#t:Weak">Weak</a> v -> <a href="System-IO.html#t:IO">IO</a> (<a href="Data-Maybe.html#t:Maybe">Maybe</a> v)</p><div class="doc"><p>Dereferences a weak pointer. If the key is still alive, then
<code><code><a href="Data-Maybe.html#v:Just">Just</a></code> v</code> is returned (where <code>v</code> is the <em>value</em> in the weak pointer), otherwise
<code><a href="Data-Maybe.html#v:Nothing">Nothing</a></code> is returned.
</p><p>The return value of <code><a href="System-Mem-Weak.html#v:deRefWeak">deRefWeak</a></code> depends on when the garbage collector
runs, hence it is in the <code><a href="System-IO.html#t:IO">IO</a></code> monad.
</p></div></div><div class="top"><p class="src"><a name="v:finalize" class="def">finalize</a> :: <a href="System-Mem-Weak.html#t:Weak">Weak</a> v -> <a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a></p><div class="doc"><p>Causes a the finalizer associated with a weak pointer to be run
immediately.
</p></div></div><h1 id="g:3">Specialised versions
</h1><div class="top"><p class="src"><a name="v:mkWeakPtr" class="def">mkWeakPtr</a> :: k -> <a href="Data-Maybe.html#t:Maybe">Maybe</a> (<a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a>) -> <a href="System-IO.html#t:IO">IO</a> (<a href="System-Mem-Weak.html#t:Weak">Weak</a> k)</p><div class="doc"><p>A specialised version of <code><a href="System-Mem-Weak.html#v:mkWeak">mkWeak</a></code>, where the key and the value are
the same object:
</p><pre> mkWeakPtr key finalizer = mkWeak key key finalizer
</pre></div></div><div class="top"><p class="src"><a name="v:addFinalizer" class="def">addFinalizer</a> :: key -> <a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a> -> <a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a></p><div class="doc"><p>A specialised version of <code><a href="System-Mem-Weak.html#v:mkWeakPtr">mkWeakPtr</a></code>, where the <code><a href="System-Mem-Weak.html#t:Weak">Weak</a></code> 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).
</p><p>Note: adding a finalizer to a <code><a href="Foreign-ForeignPtr.html#t:ForeignPtr">ForeignPtr</a></code> using
<code><a href="System-Mem-Weak.html#v:addFinalizer">addFinalizer</a></code> won't work as well as using the specialised version
<code><a href="Foreign-ForeignPtr.html#v:addForeignPtrFinalizer">addForeignPtrFinalizer</a></code> because the latter
version adds the finalizer to the primitive 'ForeignPtr#' object
inside, whereas the generic <code><a href="System-Mem-Weak.html#v:addFinalizer">addFinalizer</a></code> will add the finalizer to
the box. Optimisations tend to remove the box, which may cause the
finalizer to run earlier than you intended. The same motivation
justifies the existence of
<code><a href="Control-Concurrent-MVar.html#v:addMVarFinalizer">addMVarFinalizer</a></code> and
<code><a href="Data-IORef.html#v:mkWeakIORef">mkWeakIORef</a></code> (the non-uniformity is accidental).
</p></div></div><div class="top"><p class="src"><a name="v:mkWeakPair" class="def">mkWeakPair</a> :: k -> v -> <a href="Data-Maybe.html#t:Maybe">Maybe</a> (<a href="System-IO.html#t:IO">IO</a> <a href="../ghc-prim-0.2.0.0/GHC-Tuple.html#t:-40--41-">()</a>) -> <a href="System-IO.html#t:IO">IO</a> (<a href="System-Mem-Weak.html#t:Weak">Weak</a> (k, v))</p><div class="doc"><p>A specialised version of <code><a href="System-Mem-Weak.html#v:mkWeak">mkWeak</a></code> where the value is actually a pair
of the key and value passed to <code><a href="System-Mem-Weak.html#v:mkWeakPair">mkWeakPair</a></code>:
</p><pre> mkWeakPair key val finalizer = mkWeak key (key,val) finalizer
</pre><p>The advantage of this is that the key can be retrieved by <code><a href="System-Mem-Weak.html#v:deRefWeak">deRefWeak</a></code>
in addition to the value.
</p></div></div><h1 id="g:4">A precise semantics
</h1><div class="doc"><p>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?
</p><p>The behaviour is simply this:
</p><ul><li> If a weak pointer (object) refers to an <em>unreachable</em>
key, it may be finalized.
</li><li> Finalization means (a) arrange that subsequent calls
to <code><a href="System-Mem-Weak.html#v:deRefWeak">deRefWeak</a></code> return <code><a href="Data-Maybe.html#v:Nothing">Nothing</a></code>; and (b) run the finalizer.
</li></ul><p>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:
</p><ul><li> It is a member of the <em>root set</em>.
</li><li> It is directly pointed to by a reachable object, other than
a weak pointer object.
</li><li> It is a weak pointer object whose key is reachable.
</li><li> It is the value or finalizer of an object whose key is reachable.
</li></ul></div></div></div><div id="footer"><p>Produced by <a href="http://www.haskell.org/haddock/">Haddock</a> version 2.11.0</p></div></body></html>
distrib
>
Mageia
>
5
>
i586
>
media
>
core-release
>
by-pkgid
>
6e204a966e8c42d976f99a1700ce5f20
>
files
>
2329
