<div class="gmail_quote">On Sun, Dec 11, 2011 at 5:01 PM, James Wright <span dir="ltr"><<a href="mailto:james@chumsley.org">james@chumsley.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Liam,<br>
<div class="im"><br>
> Thanks James. Indeed, *formatting-test-grid* is just a throwaway to test<br>
> the formatting of grids. While a patch is OK, I would rather just not load<br>
> it.<br>
<br>
</div>Works for me; either solution will stop the corruption issue that I ran into. :)<br>
<div class="im"><br>
> However, I've long been uneasy with saved images and foreign memory; I<br>
> have no confidence that what's saved will come back.<br>
<br>
</div>I feel exactly the same way. It has become an article of faith with<br>
me that foreign pointers that get saved to a core will come back<br>
essentially uninitialized.<br>
<div class="im"><br>
> Indeed, if you are<br>
> seeing rng variable problems, then there is a deeper problem that can't be<br>
> fixed with turning a defparameter into a function.<br>
<br>
</div>Actually, my workaround (to saved rngs coming back uninitialized) kind<br>
of does boil down to converting the defparameter to a function.<br>
Fortunately it's possible to access the state of a GSL rng, so I've<br>
been checkpointing that and then restoring it into a<br>
freshly-constructed rng every time my program starts.<br>
<div class="im"><br>
> I would like to get<br>
> ideas from SBCL experts. I think the solution is likely to be<br>
> implementation dependent, but that's the place to start.<br>
<br>
</div>I'll be interested to hear if there's any realistic solution; I've<br>
mostly been assuming that it's up to me to make sure that I don't have<br>
any "live" foreign pointers when I dump core.<br>
<div class="im"><br>
> Can you generate a small example of your rng problem?<br>
<br>
</div>Certainly; I've attached a small script along with its output on my machine. </blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<font color="#888888"><br>
James<br></font></blockquote><div><br>James,<br><br>In both the case of *all-formatting-test-grids* and your *rng*, we have a defparameter, and that may be the key to a workable solution here. I asked on #lisp and SBCL does not have a way to save and restore foreign objects. So I'm thinking along the following lines: define a #'defautoload (or something) which would be like defparameter but leave the object unbound and store the thunk. It would actually bind the symbol as a symbol macro, and when you went to use it, it would invoke the thunk as an initializer; in future uses the function would merely look up the saved answer. Does this sound sensible? It would act just like a global special as defined by defparameter, except you couldn't rebind it in a let or setf. This also should be portable; nothing SBCL specific. I vaguely remember I coded up something similar to this at one point as part of something else, so I'll have to hunt around for it. This would only initialize on reload, not restore the state at dump time, but in your case and my case that's all we need.<br>
<br>The general problem of saving and restoring foreign objects in any context and any state is a tough one. SBCL provides variables *save-hooks* and *init-hooks* which could provide the jumping-off point. To restore the state of a variable shouldn't be that hard using these hooks, but if the object is buried inside some other thing, I don't know how we'd find it in general. The only avenue I can think of is that all the foreign objects are slot values in a CLOS object (if not a global special), so the symbol-macro/thunk trick could be used similarly. But without a strong motivation for doing it, I don't think it's worth the effort.<br>
<br>What do you think?<br><br>Liam<br></div></div><br>