Non-local exits via throw/rescue: Re: Timeout::Error

MenTaLguY wrote:
> On Thu, 7 Feb 2008 09:37:57 +0900, Kurt Stephens <[e-mail]> wrote:
>>   We use Timeout frequently for computations that we explicitly want to
>> stop after a specific amount of time; we have hard timing constraints.
>> If we can't compute it in time, we need to decide on a different course
>> of action.
> 
> How hard are your timing constraints?  Remember that the delivery
> of Thread#kill is not necessarily instantaneous, depending on how other
> threads are scheduled.  Would it be feasible to check a flag or an
> elapsed time during the computation itself?
>  

  I need to return /something/ to a caller within a fixed time frame or
else, let's just say, I lose an opportunity and money.  I have no
guarantees that my computation will complete in that time frame,
because, just like my caller, I'm dealing with unreliable services
outside of my control.  I'm able cut my losses by doing some recovery on
the terminated computation, and even live with cases where Thread#kill
is not instantaneous, reliable nor correct, as long as it is a small
fraction.

>> The only thing that is "exceptional" about Timeout errors is the
>> delivery mechanism.
>
> It's the delivery mechanism that's the basic problem; in a language
> with side-effects (like Ruby), it is seldom possible to write code that
> is entirely robust against asynchronous exceptions, and worse, most of
> Ruby stdlib is not robust against them, so you must avoid any stdlib
> code except simple blocking calls.

  The use of throw/rescue is a reasonable mechanism for dealing with
intentional, dynamically-scoped, non-local exits, like Timeout or
Kernel#exit, in a thread-aware language.   I'd love to see a better
solution, given that continuations seem to be deprecated.

  Can throw/rescue be changed to #=== to catch objects that are not
Exceptions?  Like:

catch_tag = [ :some_unique_object ]
begin
  throw catch_tag
rescue catch_tag => data
  do_something data
end

That would be generic, typeless and kinda cool. :)

  I don't want rescues on exceptional errors to "eat" intentional
non-local exits, just because there is a broken top-level rescue in irb
or in libraries that cannot enumerate all the possible non-local exit
exceptions classes and rethrow them correctly.  Rcov, for example,
didn't handle SystemExit correctly, so it was impossible for a program
under rcov to exit() with a exit status.

  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.

> 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.  :)

> -mental
> 

http://kurtstephens.com/