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.
Aea6cfe04952626ab630bde47ff82f89?d=identicon&s=25 Shri Borde (Guest)
on 2009-01-10 00:47
(Received via mailing list)
Attachment: kill.diff (30 KB)
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.
Cb51033949ffccd982ae32c9f890f25a?d=identicon&s=25 Tomas Matousek (Guest)
on 2009-01-10 02: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
Aea6cfe04952626ab630bde47ff82f89?d=identicon&s=25 Shri Borde (Guest)
on 2009-01-10 07:29
(Received via mailing list)
Inline...
This topic is locked and can not be replied to.