On Tue, Mar 18, 2008 at 02:04:40PM +0900, Tanaka Akira wrote:
> It is because Thread.check_interrupt with blocking operations causes
> race conditions.

Raising an exception during a blocking write operation makes it
impossible to know how much data was written.

Similarly, raising an exception during a blocking read operation makes
it impossible to access the data that was read.

The same is true for any operation for which partial success is
possible.

> So application must choose that make a blocking operation interruption
> safe or uninterruptible.

> * Thread.blocking_interruptible(klass) { ... }
> * Thread.blocking_uninterruptible(klass) { ... }

Interesting.  Which of these two is the default?

> Another idea is about ensure clause.  Since an ensure clause is used
> to release a resource, it may delay asynchronous events as in
> Thread.delay_interrupt.

Reminds me of an old C++ interview question we used to joke about:

"While digging through source code, you discover an application which
executes entirely in the body of the destructor of a global object.
Give one or more reasons why the author may have chosen to implement the
application this way."

Paul