> While testing eclipse I sometimes saw interrupted reads occur. VMChannel > already had a mechanism for checking the interrupted status of a thread > when a system call returned early. But this wasn't used for the read() > and write() methods. This patch adds the logic. And makes my eclipse > happy again :)
I am seeing a (possibly) related issue still: java.net.SocketException: Interrupted system call at gnu.java.nio.VMChannel.connect(Native Method) at gnu.java.nio.VMChannel.connect(VMChannel.java:399) at gnu.java.nio.SocketChannelImpl.connect(SocketChannelImpl.java:174) at gnu.java.net.PlainSocketImpl.connect(PlainSocketImpl.java:281) at java.net.Socket.connect(Socket.java:437) at java.net.Socket.connect(Socket.java:397) at gnu.java.net.protocol.http.HTTPConnection.getSocket(HTTPConnection.java:681) at gnu.java.net.protocol.http.HTTPConnection.getOutputStream(HTTPConnection.java:762) at gnu.java.net.protocol.http.Request.dispatch(Request.java:292) at gnu.java.net.protocol.http.HTTPURLConnection.connect(HTTPURLConnection.java:215) at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream(HTTPURLConnection.java:481) at java.net.URL.openStream(URL.java:712) at gnu.java.awt.peer.gtk.GtkImage.<init>(GtkImage.java:266) at gnu.java.awt.peer.gtk.AsyncImage$Loader.run(AsyncImage.java:114) at java.lang.Thread.run(Thread.java:740) This happens when many URL connections are trying to connect/transfer simultaneously. Any ideas how to solve this? (I am trying to implement asynchronous image loading and this bites me right now and I suspect it's a bug in the new IO code which we probably don't want to ship.) /Roman
