<br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 11:08 AM, Max Leske <span dir="ltr"><<a href="mailto:maxleske@gmail.com" target="_blank">maxleske@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>
Thanks for your reply Eliot.<br>
<br>
Maybe you're right and serializing blocks in the way we do is not the best. In my opinion however, that's not the issue here. I don't have any deep knowledge about bytecodes and closures but as I described, the block is corrupt without *any* interaction from Fuel (at least as far as I can tell from debugging the issue). Fuel can not finish the serialization, hence there's no materialization (or reconstruction as you call it) later either. The block is simply corrupt and even changing the method so that the startpc of the block changes, does not fix the block (the value of the startpc doesn't change and is still that of the first version of the method).<br>
<br>
So what I'm worried about has nothing to do with Fuel but with the fact that it's possible to (somehow) create corrupt closures.<br></blockquote><div><br></div><div><span class="Apple-style-span">How does that happen? It doesn't happen in normal use. I can see how Fuel does it. I can't see how non-Fuel use would do it (other than deliberate construction). A closure is created by evaluating the push-closure bytecode in a specific method, and when this closure is created, it refers, through its outer context to the method object containing the evaluated </span>push-<span class="Apple-style-span">closure bytecode. Since the closure's startpc is derived from the pc of the push-closure bytecode, there is always a match.</span></div>
<div><span class="Apple-style-span"><br></span></div><div><span class="Apple-style-span">However, when Fuel serializes (IIRC) it serializes a *reference* to a method in the form of a class-name,selector pair, and this approach can obviously yield an invalid method.</span></div>
<div><span class="Apple-style-span"><br></span></div><div><span class="Apple-style-span">therefore I think it much more likely that what you;re seeing is a result of a bug in Fuel than some systemic problem with closures.</span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
<br>
>>> Bump.<br>
>>><br>
>>> Doesn't anybody feel that corrupt blocks are a problem? IMHO that's<br>
>>> something that should *never* happen.<br>
>>><br>
>><br>
</div><div class="HOEnZb"><div class="h5">>> But what's happening here is that the Fuel serializer is allowing the<br>
>> serialization of blocks without serializing their outer context and method,<br>
>> and later the reconstruction of blocks against the *wrong* version of a<br>
>> method. This is a Fuel bug. IMO the right solution is for Fuel to<br>
>> serialize the method of the block, and on reconstruction replace the<br>
>> reconstructed method with the method in the system iff the reconstructed<br>
>> method is the same as that in the system, but substitute the recinstructed<br>
>> method if it differs from the system's version (or of course if the<br>
>> system;s version is missing). this mimics the system's behaviour with<br>
>> unbound methods, where e.g. a block holds onto a method and the code of a<br>
>> class is recompiled, resulting iun that block holding onto an unbound<br>
>> method.<br>
>><br>
><br>
> Sorry, "without serializing their outer context and method" is wrong;<br>
> "without serializing their method"<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>