Re: Experimental PATCH to improve thread performance

Charlie,

In the example you gave, the target thread would defer processing 
any exception raised in it by another thread until it blocked
in the "f.close" of its ensure clause.  You realize that one cannot 
generally  defer processing exceptions during Ruby ensure clauses,
because there is no requirement that an ensure clause
must execute to completion, as control could just fall into
another (long running) processing loop.
(At least, I've got code that works this way :-)

I believe my original proposal would allow safe recovery
of damaged objects as long as that recovery did not
require that the Thread block (and thereby become interruptible).
I think the "hole" you've found is:

"What if the target thread must block as part of the process
 of repairing damaged objects?"

Here's an extension of my original proposal that should allow for
this:

I had envisioned the "interruptible" status as being a boolean.
Now, we must define four interruptible states:

true     ==>  process exceptions immediately
false    ==>  defer exception processing when not blocked
:never  ==>  defer exception processing (even while blocked)
:always ==> immediately process exceptions (even after receiving one)

A thread's initial interruptible status is still "false" in this enhanced
proposal.  The :always status is dangerous and is included mainly
because this is the way Ruby currently works.

Here's how we might make the ensure clause of your example "safe":

begin  #Thread.interruptible == false
   f = File.open
   # do something with file
ensure  #note that Thread.interruptible is still "false"
   #we want to ensure that this clause runs
   #uninterrupted, even though it may block.
   Thread.interruptible = :never
     f.close  # or whatever blocking cleanup is required
   Thread.interruptible = false
end

This idiom would likely become common, so one could
encapsulate it in a Thread.uninterruptible{} method 
and write the ensure clause like this:

ensure
  Thread.uninterruptible {f.close}
end

The recommended way to write thread safe exception
processing code would be to simply enclose
all non-trival recovery processing in Thread.uninterruptible{}
and never to manipulate the thread's interruptible status
explicitly.

The only reason I could see to explicitly set a thread's
interruptible status to "true" would be the case where
it was doing some very time consuming computations
that *never blocked*.  If you wanted to introduce explicit
synchronization points (to such compute bound code)
at the Ruby level, you could
briefly set interruptible to true and then back to false.

Does this get us any closer the the goal of
allowing careful Ruby programmers to produce safe
code that uses thread#raise and its ilk?

- brent


Charles Oliver Nutter-2 wrote:
> 
> 
> The only hole I can think of is that even if a thread was marked 
> interruptible, you still would run the risk of raising an exception in 
> ot at a bad time:
> 
> begin
>    f = File.open
>    # do something with file
> ensure
>    # what happens if we raise here?
>    f.close
> end
> 
> No amount of marking the thread interruptible would ever make it safe to 
> raise in it arbitrarily since it would never be possible to ensure
> anything.
> 
> Or perhaps I'm not seeing how your idea prevents this?
> 
> - Charlie
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Experimental-PATCH-to-improve-thread-performance-tp14409855p14508952.html
Sent from the ruby-core mailing list archive at Nabble.com.