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@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
