From: Roger Pack <rogerpack2005@...>
Date: 2008-03-19T03:16:05+09:00
Subject: Re: Thread#raise, Thread#kill, and timeout.rb are unsafe

> Thread.current.raises do |exception|
>    queue.push exception
> end
> 
> ....
> 
> event_loop do
>    long_running_stuff
>    if exception = queue.pop
>      ...
>    end
> end
> 
> seems like it would address a ton of issued without overly
> complicating ruby's internals - just provide an 'on raise' handler.

This looks nice!

I wish that a handler like this could be "unhandled," as well, as you 
have the flexibility to handle exceptions only in parts of the code. 
Say we call your first block of code as queue_future_exceptions

Then you could have code like

Thread.current.queue_future_exceptions
  # code in here is uninterruptible
Thread.current.no_longer_queue_future_exceptions # so I don't have to 
worry about them EVERYWHERE in my code--only at the end of certain 
blocks.
Thread.current.raises do |exception| ; end

So basically it would allow for uninterruptible blocks.  That's what I 
wish we had.


In response to Mental's questions of concurrency problems for raises 
injected whilst you are in the middle of handling raises, some options 
that might help:

1) protect the queue with mutexes--add them to the end of the queue 
atomically.
2) dare I say it, require the exception handling to be either within or 
without of an "uninterruptible block" --that is, allow the exception 
handling to be interrupted (itself), or prevent it from being 
interrupted, always, to provide for sanity.

The first option (require handling outside of an uninterruptible block) 
would allow for us to "not have to worry" about concurrency of adding to 
the exception queue, since we no longer add to the queue but just raise 
on the thread.  It would allow it to be interrupted, which might be 
annoying, however, and isn't our purpose to "avoid" those pesky 
asynchronous interrupts?

The second option (requiring handling within an uninterruptible block) 
avoids handling's being interrupted, however, it could "miss" an 
interrupt or two, should they be raised between when we handle them and 
when an "uninterruptible block" ends.

So I guess the best way to deal with it would be to surround queue 
addition with mutexes, and handle them both right before an 
uninterruptible block ends, and again right after it ends.

Ok so not such a great idea.
Thoughts?
-- 
Posted via http://www.ruby-forum.com/.