Hi Laurent,
You used the term "block" below. I don't know enough about the code
yet but I would assume that "block" means either a basic block or
something between curly braces. Those entities do not have "ensure"
-- (oh, gee, you used the term block here too...) Anyway. My
thought / suggestions / question is perhaps making the things between
curly braces simple and the things between "begin" and "end" (which
can have ensure statements) more complex. The point is that curly
braces come up much more often and keeping them simple and fast would
be nice.
I'm also worried that the use of exceptions to implement often used
paths like "return" may be very expensive. Depending upon the
implementation, exceptions can cost 0 for the non-exception case but
the processing of an actually exception is very expensive. It would
be nice if that cost would only be incurred in very rare cases.
On Jul 9, 2009, at 2:50 PM, Laurent Sansonetti wrote:
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
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
