Oops. Sorry, wrong ticket.  Please ignore this.


2011/1/19 Yusuke ENDOH <mame / tsg.ne.jp>:
> 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.  > (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.  
> eliminate only Thread#raise (and #kill) is not facing the reality.
>
> Fortunately, there are some ancient wisdoms:
>
>  "cancellation points" of pthread
>  𺯯󮷮
>
>  Asynchronous Exceptions in Haskell
>  𺯯齱
>
> These two are based on a very similar idea: providing a feature
> to control whether asynchronous exceptions may be raised or may
> not.         
> article.     >
>> 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.     > former (cancellation points), and can be implemented even in
> imperative programming language, as pthread does.   
> 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.  > 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.       > case of timeout.rb?    >
> --
> Yusuke Endoh <mame / tsg.ne.jp>
>
>



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