Forum: IronRuby Code Review: Issues with Thread#kill and raising exception from ensure clause

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Shri B. (Guest)
on 2009-01-10 01:47
(Received via mailing list)
Attachment: kill.diff (0 Bytes)
tfpt review "/shelveset:kill;REDMOND\sborde"

  Comment  :
  Added more tests for Thread#kill, and fixed bugs that were exposed.
Throwing an exception from the ensure clause exposes new code paths.

  Ruby allows Thread#kill to be completely subverted (not just deferred
as an infinite loop in an ensure clause would do) by raising an
exception from a ensure clause. I have not matched that behavior, and
left it as a IronRuby bug for now.
Tomas M. (Guest)
on 2009-01-10 03:19
(Received via mailing list)
Are any methods in RubyOps Exceptions #region (including those added by
this shelveset) emitted to IL? If not they should rather be in RubyUtils
class.

On the other hand, SourceUnitTree.CheckForAsyncRaiseViaThreadAbortshould
should be marked as [Emitted], be in RubyOps.cs and
SourceUnitTree.GenerateCheckForAsyncException should use
Methods.CheckForAsyncRaiseViaThreadAbort to get the method.

Could we add a public helper that calls thread.Abort(new
ThreadExitMarker()); move the private ThreadExitMarker class and
IsRubyThreadExit to RubyUtils? Then we won't need to duplicate the
marker class in ThreadOps?

Other than that, looks good.

Tomas
Shri B. (Guest)
on 2009-01-10 08:29
(Received via mailing list)
Inline...
This topic is locked and can not be replied to.