From: Meinrad Recheis <meinrad.recheis@...>
Date: 2007-05-02T00:45:57+09:00
Subject: Re: question about frame_unique

------=_Part_26376_32027590.1178034354938
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/1/07, Paul Brannan <pbrannan@atdesk.com> wrote:
>
> I was reading the source code for ruby 1.8.6, and a thought occurrred to
> me.  Consider:
>
> - Assume we're running on a 32-bit system that has a limit of 2**32-1
>   for unsigned long.
> - frame_unique starts at 0.  Assume some amount of work has been done
>   and it reaches some number, say 20.
> - The script makes 2**32-1 method invocations and pushes and pops
>   2**32-1 frames.
> - frame_unique is incremented 2**32-1 times.  Its value should now be
>   19.
> - On the next method invocation, when the frame is pushed, frame_unique
>   will be incremented to 20, and the next frame's uniq value will be the
>   same as the previous frame's.  Ruby can now no longer distinguish
>   between the two frames, even though they are distinct frames.
>
> I don't know what the implications are of this, so I don't have a test
> case.  It's seems though that in a very long running ruby script that
> this could be a real problem.  I don't see any simple way around it,
> though.
>
> A similar problem exists with block_unique.
>
> Paul


the question is: what does this mean for long running applications in ruby?

------=_Part_26376_32027590.1178034354938
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/1/07, <b class="gmail_sendername">Paul Brannan</b> &lt;<a href="mailto:pbrannan@atdesk.com">pbrannan@atdesk.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I was reading the source code for ruby 1.8.6, and a thought occurrred to<br>me.&nbsp;&nbsp;Consider:<br><br>- Assume we&#39;re running on a 32-bit system that has a limit of 2**32-1<br>&nbsp;&nbsp;for unsigned long.<br>- frame_unique starts at 0.&nbsp;&nbsp;Assume some amount of work has been done
<br>&nbsp;&nbsp;and it reaches some number, say 20.<br>- The script makes 2**32-1 method invocations and pushes and pops<br>&nbsp;&nbsp;2**32-1 frames.<br>- frame_unique is incremented 2**32-1 times.&nbsp;&nbsp;Its value should now be<br>&nbsp;&nbsp;19.<br>- On the next method invocation, when the frame is pushed, frame_unique
<br>&nbsp;&nbsp;will be incremented to 20, and the next frame&#39;s uniq value will be the<br>&nbsp;&nbsp;same as the previous frame&#39;s.&nbsp;&nbsp;Ruby can now no longer distinguish<br>&nbsp;&nbsp;between the two frames, even though they are distinct frames.
<br><br>I don&#39;t know what the implications are of this, so I don&#39;t have a test<br>case.&nbsp;&nbsp;It&#39;s seems though that in a very long running ruby script that<br>this could be a real problem.&nbsp;&nbsp;I don&#39;t see any simple way around it,
<br>though.<br><br>A similar problem exists with block_unique.<br><br>Paul</blockquote><div><br>the question is: what does this mean for long running applications in ruby?<br></div><br></div><br>

------=_Part_26376_32027590.1178034354938--