Hi,

2011/1/19 Charles Nutter <redmine / ruby-lang.org>:
> I tried to patch this many times, and it's very difficult. The problem here is that kill is inherently broken in the presence of an ensure block. I've discussed this on ruby-core emails in the past and on my blog here: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html


This is not just a problem of Thread#raise.  Asynchronous signals
(such as Interrupt caused by Ctrl+C) have the same problem.
Of course, we cannot remove Ctrl+C.

Thus, to address this problem faithfully, we should provide a
mechanism to safely handle asynchronous exceptions.  Lobbying to
eliminate only Thread#raise (and #kill) is not facing the reality.

Fortunately, there are some ancient wisdoms:

  - "cancellation points" of pthread
    http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html

  - Asynchronous Exceptions in Haskell
    http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.1040

These two are based on a very similar idea: providing a feature
to control whether asynchronous exceptions may be raised or may
not.  In fact, the latter is referred in comments of your blog
article.  But it was rejected as:

> there are a lot of additional problems when implementing it in an environment that isn't as functionally pure as Haskell

I guess that this is misinterpretation.  It is very similar to the
former (cancellation points), and can be implemented even in
imperative programming language, as pthread does.  I don't know
that they are compatible with Java (and/or JRuby) threads, though.


On a separate note, I'm not against deprecating Thread#raise.
It is indeed too difficult to use correctly.  Just eliminating it,
however, is not enough.


> the child thread may still wake up between the end of the user-defined block and the call to kill


Yes, it may occur.  But does it cause any actual problem in the
case of timeout.rb?  Kosaki's patch seems to me good.

-- 
Yusuke Endoh <mame / tsg.ne.jp>