[ruby-core:34619] Re: [Ruby 1.9-Bug#4283] Timeout.timeout may cause application exit unintetionally

On Wed, Jan 19, 2011 at 4:32 AM, Yusuke ENDOH <[e-mail]> wrote:
> I guess that you misunderstand cancellation points.  They do not mean
> context-switch boundaries.

I think you misunderstood me. I know what cancellation points are. I
just meant that in JRuby the cancellation points are roughly the same
places in code where MRI has context switches. We designed it this way
because MRI hands off async thread events by context-switching. This
seemed like the closest analog.

For example, MRI 1.8 will check for a context switch when evaluating a
literal "false". In JRuby, evaluating a literal "false" will ping for
a raise or kill event on the current thread; in essence, literal
"false" is a cancellation point in JRuby.

There are numerous other places during code evaluation and method
invocation where we ping for thread events: IO operations, every N
calls, after thread-related operations, and so on.

So I repeat: JRuby implements kill and raise using a mechanism similar
to cancellation points, and those points occur at roughly the same
places during execution that MRI 1.8 would context switch between
threads.

> Usually, an operation that may suspend the execution is defined as
> cancellation points, such as blocking I/O, synchronization and sleep.
> In terms of Ruby, they roughly mean any operation that may change
> Thread#status to "sleep", such as IO#read, Mutex#lock, and sleep.

These are all places where we check thread events for kill and raise.
One such example:

RubyKernel.sleep calls RubyThread.sleep:

https://github.com/jruby/jruby/blob/master/src/org/jruby/RubyKernel.java#L826

RubyThread.sleep polls for thread events before and after the actual
sleep operation:

https://github.com/jruby/jruby/blob/master/src/org/jruby/RubyThread.java#L759

pollThreadEvents checks thread "mail":

https://github.com/jruby/jruby/blob/master/src/org/jruby/RubyThread.java#L759

checkMail looks for KILL or RAISE events and responds accordingly:

https://github.com/jruby/jruby/blob/master/src/org/jruby/RubyThread.java#L151

Unless a JRuby thread reaches a point that calls pollThreadEvents,
asynchronous KILL and RAISE will not be triggered. I feel this is very
similar to cancellation points.

> It is important for a programmer to be able to control whether his
> own program contains cancellation points or not.

That would be wonderful. Currently, as I mentioned in previous email,
there need to be too many cancellation points, since MRI will respond
to asynchronous kill and raise in *many* places. If we could reduce
the number of those places and make it more explicit, it would be
easier to control when asynchronous thread events should be handled
and when they should be ignored.

>> I must reiterate, however, that this is only a band-aid. Because Ruby
>> is not "functionally pure", a top-level method might wrap everything
>> in an ensure block. Should the entire application disable kill/raise?
>
> No, not at all.
> According to that mechanism, asynchronous exceptions are raised when
> you run any calcellation point operation, even when asynchronous
> exceptions are prohibited.
>
>  begin
>  ensure
>
>    foo.bar # an Interrupt may not be raised
>            # (unless these methods do not contain cancellation points)
>
>    sleep 1 # cancellation point; an Interrupt may be raised here
>
>    baz.qux # an Interrupt may not be raised
>
>  end

And it's certainly possible that calls within an ensure can trigger
other exceptions, so once the ensure starts to run you obviously can't
assume it will complete in all cases. Currently, Ruby responds to
those asynchronous events on too fine-grained of boundaries (even
responding to them as a result of making N calls!). In order for
asynch thread events to be made "safe", we need to coarsen these
boundaries and potentially allow users to opt out of them.

- Charlie