From: Brent Roman <brent@...>
Date: 2012-12-01T04:10:21+09:00
Subject: [ruby-core:50407] Re: [ruby-trunk - Feature #6762][Open] Control interrupt timing

OK.  I see the logic in using the term "interrupt" if you are actually
trying to unify exceptions from other threads with handling of OS
signals.  However,  both of these are generally thought of as being
asynchronous events.

Try googling (with the quotes):

"asynchronous interrupt*"  =>  1,130,000 results
"synchronous interrupt*" =>  180,000 results

If you insist on the async_* prefix, you should apply it consistently.
But, Thread.control_async_interrupt(  is getting quite cumbersome, no?

As someone who was writing ISRs for Intel 8080's and Zilog Z-80's in the
late 1970's, here are my suggestions for more conventional vocabulary:

Thread.control_interrupt  becomes   Thread.interruptible
  alternatives would be:
     Thread.allow_interrupt or Thread.enable_interrupt
Any of these read better (to a native English speaker).
I like interruptible because it is a *property* of the thread being
assigned by the construct.  After all, nothing actually happens when
this construct is executed.  It affects what (might) happen later:

   th = Thread.new{
      Thread.interruptible(RuntimeError => :on_blocking){
          ...
      }

In General:
   Code within the block passed to the Thread.interruptible method may
or may not be interrupted according to the specification passed as its
Hash argument.

In the example above, within the block passed to Thread.interruptible,
the thread becomes interruptible by any RuntimeError when/if
it waits for I/O or stops.

=====

The method :async_interrupted? would be better named:
  :interrupts_pending?
A thread is not interrupted if it has interrupts being deferred.
The accepted idiom for this is is to say the thread has interrupts
pending for it.

The use case for defining interrupts_pending? method as Thread instance
method is summarized on one word:  debugging!

If you have a complex application that has threads which seem to be
unresponsive, you'll want some way to tell whether those threads are
ignoring pending interrupts, or whether they are not even getting
interrupts delivered to them.

I'd also suggest adding another method:

   Thread#interrupts_pending   #without the question mark

This would return the number of pending interrupts for the thread.
A thread might normally have 0, 1 or 2 pending interrupts.  Seeing
dozens  pending would indicate a performance problem.  This would be
very useful information for debugging and optimization. A thread might
even decide to take some drastic action to if it discovers that it has
too many interrupts pending for itself.

Making Thread.current.raise act like sending exceptions to any other
thread seemed more consistent to me because the method's behavior then
has no special case for Thread.current.  I have written low level code
what processed a hardware interrupt, but then decided it must defer it
for later and accomplished this by making the interrupt pending again,
in the controller chip, but masked the interrupt in the CPU.  However, I
can see where this might break existing code that currently relies on
Thread.current#raise being exactly synonymous with Kernel#raise
Either behavior is workable.

- brent

-- 
Posted via http://www.ruby-forum.com/.