From: SASADA Koichi <ko1@...>
Date: 2012-11-30T19:12:47+09:00
Subject: [ruby-core:50387] Re: [ruby-trunk - Feature #6762][Open] Control interrupt timing

(2012/11/30 18:59), Brent Roman wrote:
> Koichi,
> 
> Sorry about misspelling your name in my previous post. :-(

Kosaki-san is also a member of this discussion.

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

Now, I unify the name "async_interrupt".  For example, "Interrupt"
exception by C-c should be included (but now, it not supported).

I want to separate normal (sync) exception and async exception.

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

Any use case?

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

No.

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

Now, Thread.current.raise is not async.
Because there is a test case it expect it is synchronous.
(No strong reason)


Thank you for your comment. But I can't accept the method name with
simple *exception*.  I want to emphasize it is *asynchrnous* and very
internal method.

In fact, Kosaki-san also don't like *async_interrupt*.  We are very
welcome to propose good name.

But I feel "async_interrrupt_timing" and "async_interrupted" is good
name.  Of course, it is not a best name, I agree.

Thanks,
Koichi

-- 
// SASADA Koichi at atdot dot net