From: SASADA Koichi <ko1@...>
Date: 2012-11-26T09:45:57+09:00
Subject: [ruby-core:50136] Re: [ruby-trunk - Feature #6762] Control interrupt timing

(2012/11/03 8:33), kosaki (Motohiro KOSAKI) wrote:
>> Okay.  Give us a good name.
> 
> How's this?
> 
> control_interrupt() => defer_async_raise() or defer_unwinding()
> 
> "control" is unclear and don't explain what action does. Actually this procedure block provide a defer way.
> and "interrupt" is often used for other meanings then I think to avoid it is better.

`immediate' does not defer.
I can't accept the name `defer_*'.

> never => end
> 
> "never" seems a word to drop an exception. I like to say "defer to end of block"

`end' is also unclear.  how about `defer'?

> 
> below is a rough and draft documentation idea.
> 
>> a exception is queueed and exception raising  will be deferred to an end of control_async_raise block.
>> a queued exception never be lost.
> 
> 
> :on_blocking => raise_point
> 
> I prefer to use foo_point rather than "block" because unblocking built-in may allow an exception raise in future.
> example, recently we decided to release in zlib even though it doesn't take an IO. I except zlib and other long calculation
> method also prefer to allow to raise exceptions.
> 
> below is a rough and draft documentation idea.
> 
>> an exception will be only raised on implicit or explicit on raise point.
>> almost IO and built-in blockable operation provide implicit raise point
>> and Thread.may_raise() provide explicit one.

How about `blockable_point' ?

> Thread.check_interrupt => Thread.may_raise
> 
> "check" is also unclear word to me. and It seems to return boolean value of checking result. I think "check" is what does.
> and people want to know what's happen. then I propose may_raise.

It inspired from `CHECK_INTS' from C source code.
I feel `may_raise' is strange.

-- 
// SASADA Koichi at atdot dot net