From: SASADA Koichi <ko1@...>
Date: 2012-07-25T18:22:26+09:00
Subject: [ruby-core:46754] Re: [ruby-trunk - Feature #6762][Open] Control interrupt timing

(2012/07/21 15:41), KOSAKI Motohiro wrote:
>> * Thread.control_interrupt
>> * Thread.check_interrupt
> 
> Eek. Please don't use 'interrupt' word. It makes a lot of confusing to
> Unix programmer.

Okay.  Give us a good name.


>> Rdoc documents are:
>>
>>   call-seq:
>>     Thread.control_interrupt(hash) { ... } -> result of the block
>>
>>   Thread.control_interrupt controls interrupt timing.
>>
>>   _interrupt_ means asynchronous event and corresponding procedure
>>   by Thread#raise, Thread#kill, signal trap (not supported yet)
>>   and main thread termination (if main thread terminates, then all
>>   other thread will be killed).
> 
> No. control_interrupt should NOT inhibit running trap procedure. Because of,
> Thread.control_interrupt() is per-thread, but trap is not per-thread.

It is not reason.  trap handler and an exception from trap handler
interrupt (ah, you don't like this word) ensure clause.  It is problem.

Kosaki-san and me talked about it at IRC.  Kosaki-san proposed that an
exception from trap handler should be caused as `Thread#raise'.  It can
protect from this feature.  It seems good.  I think mask signal trap
with this feature is more simple.

Any other ideas or comments?


> btw, Probably it should be per-fiber instead of per-thread.

Okay.

>>   _hash_ has pairs of ExceptionClass and TimingSymbol.  TimingSymbol
>>   is one of them:
>>   - :immediate   Invoke interrupt immediately.
>>   - :on_blocking Invoke interrupt while _BlockingOperation_.
> 
> I don't think 'on_blocking' is good name. Example, pthread cancel have
> a 'cancellation point' concept and many blocking functions is defined
> as cancellation point. but a few non blocking functions also defined
> as cancellation point. So, this on_blocking should have a name as
> concept likes interruptible point. (but again, i don't like interrupt
> word)

Akr-san proposed `on_blockable'.  Any other ideas?

-- 
// SASADA Koichi at atdot dot net