[ruby-core:50542] Re: [ruby-trunk - Feature #6762][Open] Control interrupt timing

I was suggesting "interruptible" as a better alternative for
"async_interrupt_timing" or "control_interrupt".  Can either be called
without a block?  If so, does it change the way subsequent interrupts
are delivered?

I'd like to avoid the use of "async" because it is an abbreviation for
asynchronous.  Ruby core method names tend of avoid abbreviations.  That
helps make the language more readable.

In light of all the ways "async_interrupt_timing" method can be used,
perhaps (even better :-) alternative names would be:

  accept_interrupt(X => :immediately)
  accept_interrupt(Y => :on_blocking)
  accept_interrupt(Z => :never)

Or:

  handle_interrupt(X => :immediately)
  handle_interrupt(Y => :on_blocking)
  handle_interrupt(Z => :never)

Handle interrupt X immediately.  Handle interrupt Y on_blocking.
Handle interrupt Z never.  You could also write:

  asynchronous_event(X => :immediate)
  asynchronous_event(Y => :on_blocking)
  asynchronous_event(Z => :defer)

Or, (but this is getting a bit too long):

  handle_asynchronous_event(X => :immediately)
  handle_asynchronous_event(Y => :on_blocking)
  handle_asynchronous_event(Z => :never)

My vote is for handle_interrupt or asynchronous_event, but all these
read as idiomatically correct English jargon.  I adjusted the values in
the hashes slightly when using a verb phase for the method name to make
the resulting syntax more consistent with English grammar.

The
  Thread#pending_interrupt?

method name you propose is also perfectly good English.
Either name is much more descriptive than Thread#async_interrupt?


But, enough syntax.  Let's move on to semantics:

It is vital that further interrupts for a thread be deferred immediately
after any asynchronous exception is raised in it.  There is no
other way to guarantee that ensure clauses run to completion.  This
deferral must happen even when the delivery policy is X=>:immediate !
Charles pointed this out earlier.  I just assumed this would be the
case.  Can you please confirm?

My five year old proposal incorporated to two similar interrupt deferral
policies to deal with the above issue.  One was analogous to your
:immediate, the other was called :always. The :always policy operated
exactly as Ruby does today.  No interrupt queues or deferral.  It is
intended to provide compatibility with existing Ruby code, however
conceptually flawed.


This new proposal adds the ability to
assign different exception delivery policies to each subclass of
Exception.
This seems good on the surface, but won't it complicate the queue
management and make it possible for exceptions to be delivered out of
order?  Have you thought about this?

Have you considered timestamping asynchronous exceptions so the
application can tell how long they had been deferred, and, much more
importantly, sort them to determine the actual order in which they
occurred?

I would suggest that, if you don't want to timestamp exceptions, you
should drop the ability to apply different delivery policies to
different object classes.


Another, less important issue, is having the ability to query the number
of interrupts in the deferral queue.  Soft real-time systems may change
their behavior depending on the perceived backlog.  But, more
importantly, seeing a large number of deferred interrupts for a thread
is a great debugging aid.  Under high loads, a boolean test would not 
provide the needed information, as there will usually be one
or two interrupts pending.

- brent

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