<div dir="ltr">Hi John,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 10:30 AM, John McIntosh <span dir="ltr"><<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">The file system gets broken likely because it uses weak logic to ensure the unix file handle gets closed when the referencing squeak file handle gets GC. <div>That speaks to the entity being GCed too early? Or something wrong in the squeak side finalization that makes the sources file object close it's file handle. ?</div><div><br></div><div>Note also if a file creation fails due to out of file handles the ancient logic there would do a full GC, hoping that there was zombie files/sockets open so that finalization would free up operating system file handles so a retry would work. </div></div></blockquote><div><br></div><div>Right, and right. But I tried for quite a few hours to put a breakpoint in the VM to find out precisely when the sources file got closed so I could diagnose it properly but failed. So I'm leaving it for when I have some time. Volunteers welcome.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 10:15 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi Esteban,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 5:39 AM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Hi,<br>
<br>
I need to change the WeakRegistry, to adapt Pharo to finalisation on Spur and I wanted to “star over”, injecting into Pharo the packages Collections-Weak and System-Finalizer from Squeak.<br>
Now, that breaks everything, of course :)<br>
<br>
So, I wonder if there is a clean way to do this?<br></blockquote><div><br></div><div>That's a great question. A few weeks ago I implemented the Ephemeron class for Squeak (I haven't committed it yet) and set about changing the finalization scheme to support both ephemerons and non-weak-registry-based weak array finalization. The latter is where the weak array that needs finalizing is added to the same VM queue that an ephemeron that needs finalizing gets added to. So instead of all WeakArrays getting finalized via the WeakRegistry mechanism every time one or more weak arrays get finalized, only the weak arrays that have actually lost a reference will get finalized. Alas, for reasons I don't understand, this broke the file system. I would use the system for some minutes and then suddenly source code viewed in the browser would be decompiled, since the source file had closed. Alas I don't have time to look at this now, but I do think very much it is the right way to go. Right now I'm busy with a long list of dependent changes that I must get fixed to make progress. So for now I can't help other than to e.g. mail you, or post, my prototype finalization changes and have you look at those and see if you can get them working in Pharo. I;m also interested in getting anyone else who would like to help involved. I am so overloaded right now it's not funny [right, ed :-) "Get some rest. If you don't have your health, you don't have anything". Count Rugen]</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">thanks,<br>
Esteban</blockquote></div><br><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">===========================================================================<br>John M. McIntosh. Corporate Smalltalk Consulting Ltd <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div></div></div>
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>