From: Brent Roman <brent@...>
Date: 2012-11-30T18:59:27+09:00
Subject: [ruby-core:50382] Re: [ruby-trunk - Feature #6762][Open] Control interrupt timing

Koichi,

Sorry about misspelling your name in my previous post. :-(

In reference to:
----------------
  * thraed.c: add Thread.async_interrupted?.
    This method check any defered async interrupts.

Ah, I want to say "This method checks any defered async interrupts are
there".
It is no ambiguous, I think.
------------------

I would suggest:
-----------------
  * thread.c: add Thread.exceptions_pending?
    This method checks for any deferred exceptions.

"This method returns true if there are exceptions pending"
---------------

I don't see why this is a class method.  What's wrong with allowing a
thread to check whether another has pending exceptions?

I, too, think that "interrupt" is a term so loaded with hardware
connotations that it should be avoided in this context.  Also, async is
sort of redundant, as all exceptions you can defer will be asynchronous
ones.

Do you propose allowing a thread to defer delivery of exceptions to
itself?
What happens if one writes:

   Thread.current.raise  Exception.new

Can this get deferred, in your new scheme?
Can the delivery of:

   Kernel.raise  Exception.new

be deferred?

Personally, I think that Thread.current.raise might get deferred, but
Kernel.raise should bypass the queuing mechanism entirely.

- brent

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