<p>This chapter describes the use of the kernel feature of <em>weak pointers</em>. This feature is primarily intended for use only in <strong class="pkg">GAP</strong> internals, and should be used extremely carefully otherwise.</p>
<p>The garbage collector (see Section <a href="chap7_mj.html#X7F1F741D7F0899D1"><span class="RefLink">7.12-1</span></a>) is the part of the kernel that manages memory in the user's workspace. It will normally only reclaim the storage used by an object when the object cannot be reached as a subobject of any GAP variable, or from any reference in the kernel. We say that any link to object \(a\) from object \(b\)keeps object \(a\)alive, as long as \(b\) is alive. It is occasionally convenient, however, to have a link to an object which does not keep it alive, and this is a weak pointer. The most common use is in caches, and similar structures, where it is only necessary to remember how to solve problem \(x\) as long as some other link to \(x\) exists.
<p>The following section <a href="chap86_mj.html#X86D963DC7968899B"><span class="RefLink">86.1</span></a> describes the semantics of the objects that contain weak pointers. Following sections describe the functions available to manipulate them.</p>
<p>A <em>weak pointer object</em> is similar to a mutable plain list, except that it does not keep its subobjects alive during a garbage collection. From the <strong class="pkg">GAP</strong> viewpoint this means that its entries may become unbound, apparently spontaneously, at any time. Considerable care is therefore needed in programming with such an object.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ WeakPointerObj</code>( <var class="Arg">list</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p><code class="func">WeakPointerObj</code> returns a weak pointer object which contains the same subobjects as the list <var class="Arg">list</var>, that is it returns a <em>shallow</em> weak copy of <var class="Arg">list</var>.</p>
<p>After some computations involving garbage collections (but not necessarily in the <em>first</em> garbage collection after the above assignment), <strong class="pkg">GAP</strong> will notice that the list and the record stored in <code class="code">w</code> are not referenced by other objects than <code class="code">w</code>, and that therefore these entries may disappear.</p>
<p>Note that <code class="code">w</code> has failed to keep its list and record subobjects alive during the garbage collections. Certain subobjects, such as small integers and elements of small finite fields, are not stored in the workspace, and so are not subject to garbage collection, while certain other objects, such as the boolean values, are always reachable from global variables or the kernel and so are never garbage collected.</p>
<p>Subobjects reachable without going through a weak pointer object do not evaporate, as in:</p>
<p>Note also that the global variables <code class="code">last</code>, <code class="code">last2</code> and <code class="code">last3</code> will keep things alive –this can be confusing when debugging.</p>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ SetElmWPObj</code>( <var class="Arg">wp</var>, <var class="Arg">pos</var>, <var class="Arg">val</var> )</td><td class="tdright">( function )</td></tr></table></div>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ UnbindElmWPObj</code>( <var class="Arg">wp</var>, <var class="Arg">pos</var> )</td><td class="tdright">( function )</td></tr></table></div>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ ElmWPObj</code>( <var class="Arg">wp</var>, <var class="Arg">pos</var> )</td><td class="tdright">( function )</td></tr></table></div>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ IsBoundElmWPObj</code>( <var class="Arg">wp</var>, <var class="Arg">pos</var> )</td><td class="tdright">( function )</td></tr></table></div>
<div class="func"><table class="func" width="100%"><tr><td class="tdleft"><code class="func">‣ LengthWPObj</code>( <var class="Arg">wp</var> )</td><td class="tdright">( function )</td></tr></table></div>
<p>The functions <code class="func">SetElmWPObj</code> and <code class="func">UnbindElmWPObj</code> set and unbind entries in a weak pointer object.</p>
<p>The function <code class="func">ElmWPObj</code> returns the element at position <var class="Arg">pos</var> of the weak pointer object <var class="Arg">wp</var>, if there is one, and <code class="keyw">fail</code> otherwise. A return value of <code class="keyw">fail</code> can thus arise either because (a) the value <code class="keyw">fail</code> is stored at position <var class="Arg">pos</var>, or (b) no value is stored at position <var class="Arg">pos</var>. Since <code class="keyw">fail</code> cannot vanish in a garbage collection, these two cases can safely be distinguished by a <em>subsequent</em> call to <code class="func">IsBoundElmWPObj</code>, which returns <code class="keyw">true</code> if there is currently a value bound at position <var class="Arg">pos</var> of <var class="Arg">wp</var> and <code class="keyw">false</code> otherwise.</p>
<p>Note that it is <em>not</em> safe to write:</p>
<p><code class="code">if IsBoundElmWPObj(w,i) then x:= ElmWPObj(w,i); fi;</code></p>
<p>and treat <code class="code">x</code> as reliably containing a value taken from <code class="code">w</code>, as a badly timed garbage collection could leave <code class="code">x</code> containing <code class="keyw">fail</code>. Instead use</p>
<p><code class="code">x := ElmWPObj(w,i); if x <> fail or IsBoundElmWPObj(w,i) then . . .</code>.</p>
<h4>86.3 <span class="Heading">Accessing Weak Pointer Objects as Lists</span></h4>
<p>Weak pointer objects are members of <code class="code">ListsFamily</code> and the categories <code class="func">IsList</code> (<a href="chap21_mj.html#X7C4CC4EA8299701E"><span class="RefLink">21.1-1</span></a>) and <code class="func">IsMutable</code> (<a href="chap12_mj.html#X7999AD1D7A4F1F46"><span class="RefLink">12.6-2</span></a>). Methods based on the low-level functions in the previous section, are installed for the list access operations, enabling them to be used as lists. However, it is <em>not recommended</em> that these be used in programming. They are supplied mainly as a convenience for interactive working, and may not be safe, since functions and methods for lists may assume that after <code class="code">IsBound(w[i])</code> returns <code class="keyw">true</code>, access to <code class="code">w[i]</code> is safe.</p>
<p>A <code class="func">ShallowCopy</code> (<a href="chap12_mj.html#X846BC7107C352031"><span class="RefLink">12.7-1</span></a>) method is installed, which makes a new weak pointer object containing the same objects as the original.</p>
<p>It is possible to apply <code class="func">StructuralCopy</code> (<a href="chap12_mj.html#X7C1E70587EBDD2CB"><span class="RefLink">12.7-2</span></a>) to a weak pointer object, obtaining a new weak pointer object containing copies of the objects in the original. This <em>may not be safe</em> if a badly timed garbage collection occurs during copying.</p>
<p>Applying <code class="func">Immutable</code> (<a href="chap12_mj.html#X7F0ABF2C870B0CBB"><span class="RefLink">12.6-3</span></a>) to a weak pointer object produces an immutable plain list containing immutable copies of the objects contained in the weak pointer object. An immutable weak pointer object is a contradiction in terms.</p>
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.
