Re: Experimental PATCH to improve thread performance

Brent Roman wrote:
> I think the "hole" you've found is:
> 
> "What if the target thread must block as part of the process
>  of repairing damaged objects?"

This isn't really the hole I meant, but I'll endulge you for the moment :)

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

I guess I'm not getting when exceptions would be processed. Not until 
you set interruptible = true? Would the act of setting it immediately 
process exceptions? Perhaps we should be talking about an API where the 
target thread can "opt in" to exceptions it has been told to raise 
externally? I don't see a way to make Thread#raise safe unless the 
target thread remains in control of its destiny.

> 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 problem I have with this is that the Thread#raise event might be 
received after entering the ensure clause but before the call to 
uninterruptible, since ensure + uninterruptible is not atomic.

Opt-in would make this instead...

ensure
   f.close
   Thread.process_exceptions
end

Which is marginally safer than having the exceptions just "happen" when 
you set interruptible = true or in the current model where they just 
"happen" pretty much at random. But it doesn't solve the core problem 
that the target thread *must* be a willing participant in the 
transaction, by both being prepared for the raised exception and being 
able to handle the raised exception. Anything that makes it happen 
magically for threads that don't opt-in is going to be unsafe.

> 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?

It seems like people want Thread#raise to survive as a message-passing 
mechanism. But why? Exception raising as message-passing doesn't seem 
like a good idea to me. Why not simple add a new API to core, probably 
based on thread.rb primitives (or fastthread, which is how thread.rb is 
implemented in JRuby) like this:

th = Thread.new {
   puts Thread.receive
}

th.send :hello

Where Thread#send and Thread::receive can be used to pass arbitrary data 
across the thread boundary. If you really want to pass exceptions...

class Thread
   def raise(ex = RuntimeException.new)
     send ex
   end

   def Thread.reraise
     ex = receive
     raise TypeError.new unless Exception === ex
     raise ex
   end
end

th = Thread.new {
   Thread.reraise
}

th.raise

And of course this is strikingly similar to Fiber (but not quite, since 
I think transfer only works across fibers...yes?)

require 'fiber'

f = Fiber.new {
   # class-level transfer method just used for exchange with...
   puts Fiber.transfer
}

# ...instance-level transfer from somewhere else
f.transfer :hello

Since Fiber semantics can easily map to threads (and in fact Fibers in 
JRuby are implemented using threads), perhaps require 'fiber' should add 
similar behaviors to Thread itself?

require 'fiber'

th = Thread.new {
   puts Thread.transfer
}

th.transfer :hello

This is almost certain to be a much cleaner and safer way to do 
information-passing across threads. It's also worth noting that you can 
do this in Ruby 1.8 using Queue:

require 'thread'

q = Queue.new

th = Thread.new {
   puts q.pop
}

q.push :hello

There are far safer and more efficient ways to pass information across 
threads than using exceptions and Thread#raise.

- Charlie