From: MenTaLguY <mental@...>
Date: 2008-03-20T07:21:06+09:00
Subject: Re: Thread#raise, Thread#kill, and timeout.rb are unsafe

On Thu, 20 Mar 2008 05:57:02 +0900, Paul Brannan <pbrannan@atdesk.com> wrote:
> On Thu, Mar 20, 2008 at 03:50:13AM +0900, MenTaLguY wrote:
>> There are really two alternatives:
>>
>>  1. fix the operation so that it succeeds or fails atomically
>>
>>  2. otherwise, make the operation always non-interruptable
> 
> For I/O operations, it is typically desirable for the operation to be
> interruptible, but to get the result of the partial operation after it
> is interrupted.  At least, that's how it works at the C level with
> respect to signals.

Yes.  For my purposes, partial success is still success as long
as the caller can tell how far it got.  Even in the absence of
signals, a successful write() isn't guaranteed to write everything
that was requested.  The important thing is that the operation
doesn't report total failure when it really succeeded, or vice-versa.

Historical example:  under SVR4, a write() interrupted by a signal
would always fail with EINTR, even if some bytes had already
been written.  POSIX later remedied this, so that write() would
always report success if any bytes were written, even if it was
interrupted by a signal.  In that instance, the API was modified
to conform to alternative #1.

Now, the question with IO and asynchronous exceptions in Ruby is
whether there is a good way to report a partial result?

-mental