> I was looking into getting InterruptedIOException to get raised properly when
> doing IO and have some issues with the C native methd sysReadFD(). Function
> sysReadFD() is in files .../native_threads/io_md.c and
> .../green_threads/io_md.c.
>
> From looking at the source code for sysReadFD() in .../green_threads/io_md.c,
> it looks like sysReadFD() should return a function result of -2 if the thread
> was interrupted when doing the read.
>
> However, when I looked at the places where sysReadFD() gets called (in module
> src/share/java/lang/io.c), the status of -2 is never checked. So, how does
> InterruptedIOException get raised when a thread is interrupted in the middle
> of calling sysReadFD() ?

Implementation of native_thread and green_thread have different thread models.

In native_thread implementation of sysReadFD(), read system call is blocked
by generating its own thread signal mask (Solaris thread library will create
new LWP to handle this). There is no -2 return code in this implementation.
 
In green_thread implementation of sysReadFD(), the green thread blocking call
will be converted to non-blocking call within its implementaiton
for the green_thread scheduler to use proper time slices
(I am not very familiar with green thread scheduler).
The -2 return code is generated upon read interruption.

In java.io package API, most read methods generates only IOException
not InterruptedIOException, generic exceptions for both green & native
implementation. No matter what threads you use, there is no
InterruptedIOException raised for read.
The java Language specification outlines IO APIs in Ch22, the package java.io.
As for using java.io, no interrupted exception needs to be defined.
Which is the current implementation, and resonable.


However, write is a different story. As Matt pointed out earlier,
if you use the green thread write, you may get InterruptedIOException,
but not using the native thread.
Which is different then the Language spec. Looks to me that this is little
confusing, and I think that the current source code is a sanp shot of
simple fix for green thread interruptablity problem.

So I will write a rfe report for this, and we will know if it is a bug or
design intent.



> > I noticed some other anomalies with InterruptedIOException, beside the
> > sysReadFD issue.
> >
> > 1. Why isn't function sysAcceptFD() set up to return -2 ? It can block
> > the calling thread, so it seems like it should be able to cause an
> > InterruptedIOException exception.
> > It could also be argued that sysOpenFD() should be capable of causing an
> > InterruptedIOException exception. Are there defined language rules about
> > which IO APIs can throw InterruptedIOException exceptions ?
> >
> > 2. Function sysRecvfromFD is caled twice from src/solaris/net/socket.c.
> > When it is called from java_net_PlainDatagramSocketImpl_peek(), the -2 is
> > not checked for. The -2 is checked for when it is called from function
> > java_net_PlainDatagramSocketImpl_receive(). I think the missing check
> > could be a bug.
> >
> > 3. Function sysSendFD() is called from
java_net_SocketOutputStream_socketWrite
> > in src/solaris/net/socket.c. Function sysSendFD() can return -2, but a
> > result of -2 is not checked for by
java_net_SocketOutputStream_socketWrite.
> >