[MacRuby-devel] Return from thread context

[Laurent Sansonetti]

I was planning to rewrite return-from-a-block today (or maybe  
tomorrow). The current SjLj-based implementation is not correct  
because it does not call ensure blocks, so I was thinking of using a  
specialized C++ exception instead, which should do the trick.

# This was a long-standing issue but yesterday night I found a use  
case where it's problematic: Mutex#synchronize won't unlock if return  
is called from it.

Normally with the new implementation we should be able to catch the  
specialized exception inside rb_vm_thread_run() and appropriately  
raise a LocalJumpError.

Thanks for your preliminary investigation on this!

Laurent

On Jul 9, 2009, at 12:43 PM, Perry Smith wrote:

>
> The file is:
> ./spec/frozen/language/return_spec.rb
>
> I don't know how to describe which one other than the first describe  
> that starts "in a Thread"
>
> Currently it does:
>
> The return keyword in a Thread
> - raises a LocalJumpError if used to exit a threadSEGV recieved in  
> SEGV handler
> unknown: [BUG] Segmentation fault
>
> Perry
> Ease Software, Inc. ( http://www.easesoftware.com )
>
> Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX  
> systems
>
> On Jul 9, 2009, at 2:35 PM, Laurent Sansonetti wrote:
>
>> Hi Perry,
>>
>> Which spec are you talking about specifically?
>>
>> Laurent
>>
>> On Jul 9, 2009, at 5:56 AM, Perry Smith wrote:
>>
>>> The spec says that a 'return' from a thread should raise a  
>>> LocalJumpError.
>>>
>>> Looking at the code for RETURN_NODE in compiler.cpp, the question  
>>> of "Is this a thread" is never asked.  And, I guess this exception  
>>> is only for the top level block of the thread since a function  
>>> called from the block could do a return.
>>>
>>> I looked briefly at the Thread create process and I didn't see  
>>> anything that flagged the block passed as the top level block for  
>>> the thread.
>>>
>>> The testcase causes a segmentation fault.  I looked at the signal  
>>> handler too and it appears as if it is "lets do this for now and  
>>> address it later" code.  The SEGV fault handler simply sets a flag  
>>> and returns.  The return will put us back where we were just at so  
>>> we immediately seg fault again and then we do an exit -- with no  
>>> core file.
>>>
>>> I don't see the value of catching SEGV in the first place unless  
>>> the underlying Ruby code has asked us to do that.  I think that  
>>> would generally apply to all signals.
>>>
>>> Perry
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel