From: MenTaLguY <mental@...>
Date: 2008-02-09T05:11:49+09:00
Subject: Re: Non-local exits via throw/rescue: Re: Timeout::Error

On Fri, 8 Feb 2008 13:07:47 +0900, Kurt Stephens <ks@kurtstephens.com> wrote:
>   That's why there should be a different standard superclass for
> intentional non-local exits for Timeout::Error, Kernel#exit, etc. that
> is not commonly trapped for logging, etc.  I'm not really sure if a
> throwable superclass for that purpose exists in Ruby 1.8 or 1.9 by
> convention, design or at all.

I do agree on this point.  I just think we need something more along
the lines of Java's Thread.interrupt (which can inject asynchronous
exceptions only at well-defined points) instead of Thread#raise.
 
>> Given that, as long as none of the mutable objects modified by your
>> aborted computation persist past the timeout, you are okay, but that
>> is more difficult to achieve than you might naively expect.
> 
>   Agreed, side-effects are the tricky part of any recovery from any
> non-local exit: don't make side-effects that are not recoverable if
> recovery is needed.  It's not that hard.  :)

You'd be surprised.  Since you're evidently doing IO, have you
audited those libraries to make sure you aren't inadvertantly mangling
or leaking pooled resources?

As far as leaks go, it's important to realize that begin/ensure isn't
sufficient to protect against Thread#raise-style asynchronous
exceptions (there are always races surrounding the beginning of the
begin block, and depending on the Ruby implementation, the execution
of the ensure block), so it is critical that none of the code you try
to interrupt do anything that cannot be cleaned by the garbage collector
on its own.

(Most of those issues would go away if we had something like Java's
Thread.interrupt.)

-mental