This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Unblocking blocked I/O


Tom Tromey wrote:

>>>>>>"Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>>>>>>
>
>Bryce> 	* java/io/natFileDescriptorPosix.cc (write (jint)): Check for thread 
>Bryce> 	interrupted status flag only if ::write returned an error.
>
>My understanding is that write(2) can return a short (not -1) count
>when interrupted.  From the glibc manual:
>
>    `EINTR'
>          The `write' operation was interrupted by a signal while it was
>          blocked waiting for completion.  A signal will not necessary
>          cause `write' to return `EINTR'; it may instead result in a
>          successful `write' which writes fewer bytes than requested.
>
>This is why the code used to check for the interrupt unconditionally.
>I think this part of the change should be reverted.
>
Well, not throwing the InterruptedIOException is not an error (provided 
the thread interrupted status flag remains set). My testing with the IBM 
JDK on linux showed that if you called thread.interrupt() on a thread 
while it was not blocked and then it made a read() call it would not 
result in an InterruptedIOException being thrown.

Of course, the semantics of interrupt are not well defined so either 
behaviour is probibly within spec, but in this case I thought that 
matching the the JDK was the right thing to do.

regards

Bryce.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]