Re: Experimental PATCH to improve thread performance

Hi Charlie,

I've spent some time reading your post in detail and
I fear we've been talking past each other here.
Let's give it another go...


Charles Oliver Nutter-2 wrote:
> 
> 
> 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? 
> 
> 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.
> 
> 

Ignoring the :always and :never states for a moment...

External exceptions would be enqueued by the Ruby interpreter
whenever the target thread's interruptible status was false.
A thread's interruptible status would be set to true just before it blocked.  
The status would remain set to true until it unblocked for any reason.
Thus, each act of setting interruptible status to true would cause 
at most one pending exception to be raised in the target thread.
Recall that my original proposal stipulated that the interruptible status
would revert to false whenever an external exception was processed.



Charles Oliver Nutter-2 wrote:
> 
> 
> 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: ...
> 
> 

I, like many people, feel that Ruby's rich exception processing syntax is 
one of its strong points.  Thread#raise seems to have been intended
to allow exceptions to propagate among threads so that they
might be used for asynchronous inter-thread communication as well
as synchronous error handling.  I think it is worthwhile to make these
existing mechanisms work deterministically (i.e. "safely"), without
requiring logic changes to the great majority of threaded Ruby
applications.



Charles Oliver Nutter-2 wrote:
> 
> 
> ... 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.
> 
> 

I believe that the interruptible status as described *does* solve this
core problem because each thread can determine its own policy concerning
when it will accept an interrupt.  The default "magic" policy will work well
for any thread that is not compute bound.  Application programmers
will only have to take care in situations where they intend to block
while objects are in a "damaged" state.  Recall that:

Thread.interruptible=:never

could still be used for threads that wanted to explicitly control all
interactions with others.  

The "opt in" approach is exactly analogous to Thread.interruptible=:never
in that each thread must explicitly poll for interactions of others at
every conceivable synchronization.  This leads to code that is peppered
with checkpoints.  Failing to include one can result on a thread's appearing
to hang, which will often be perceived as a system failure.

Further, with "opt in", I cannot see how to reawaken a thread that is
blocked on I/O when another thread might determines that the operation 
has timed out or is for some other reason no longer relevant.
How would an "opt in" only model deal with this?



Charles Oliver Nutter-2 wrote:
> 
> 
> There are far safer and more efficient ways to pass information across 
> threads than using exceptions and Thread#raise.
> 
> - Charlie
> 
> 

We absolutely agree.

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