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

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and 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

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.

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