On Sun, Mar 14, 2010 at 7:45 PM, Ram Krishnan <span dir="ltr"><<a href="mailto:kriyative@gmail.com">kriyative@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div>Firstly, sorry for rushing off the bug report without including a test<br></div>
case.<br></blockquote><div><br>No problem. The bug report by itself is valuable, but the test case is needed to help debug the problem and the potential fix. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Secondly, I was wrong about the crashing behavior. After I'd sent my<br>
bug report, I realized I had a call to FORMAT inside of the finalizer,<br>
which is likely to cons and presumably cause unexpected behavior.<br>
Removing that call to FORMAT eliminated the crashing behavior. So,<br>
please disregard that.<br></blockquote><div><br>No, it should not be disregarded. The goal is that it is safe to execute _arbitrary_ code in the finalizers. If FORMAT broke it then obviously the code is not working fine.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
However, the issue with only part of the queued objects being gc'ed<br>
remains, as evidenced by the test case above.<br></blockquote><div><br>I will look at it carefully<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Lastly, thanks for explaining queueing_finalizer(), and I appreciate<br>
the motivation, but, I still don't follow the logic. Just so I have it<br>
right, this is what I understood from your explanation:<br>
<br>
 - new object gets assigned a finalizer<br>
 - eventually, object is marked garbage<br>
 - gc calls finalizer<br>
 - finalizer is added to a queue, and will be called when that queue<br>
becomes garbage<br></blockquote><div><br>Actually I am not sure I want the queue to be finalized when it becomes garbage, but rather as soon as possible after this or the next collection would be fine. I will have to look at the code. I am just talking out of memory content and my RAM is error prone :-)<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If a set of objects have inter-dependencies when they are first passed<br>
into queueing_finalizer() (and get pushed into to_be_finalized), won't<br>
those same dependencies exist when queueing_finalizer() is reinvoked<br>
on the to_be_finalized queue? How is the dependency situation any<br>
different in the second go around?<br></blockquote><div><br>The problem is not dependencies, but having all content sane and accessible. Finalized objects have to be valid objects when the finalizer is called and it has to be safe to execute arbitrary code in the finalizer. Given this, there is no other guarantee: no order is guaranteed when calling the finalizers and your code should be aware of that.<br>
<br>Juanjo<br></div></div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>