Hi, I reported a bug at <http://www.blackdown.org/cgi-bin/jdk/incoming?id=618;page=37;user=guest> about spurious exceptions and got a reply but I don't know how to add more comments in Jitterbug so I am sending this to the list. If this is inappropriate please give me instructions on how to add comments to an already filled bug. The bug is triggered when setSoTimeout is called on a Socket and some other conditions that are not completely clear but seem to be related to generation a lot of IO. (In the bug report I mention also calling setTcpNoDelay and generating output from System.out, but this does not seem to be the whole story but at least gives a way to reliably reproduce the bug.) When soSoTimeout is called on a Socket one would expect an java.io.InterruptedIOException after the timeout (which does sometimes occur), but you also get some spurious java.net.SocketException: Interrupted system call Exceptions from Socket methods. It looks like these SocketExceptions are thrown at random on all subsequent Socket calls. On the bug page 'kbhend' gave the following explanation: > Under native_threads we do NOT automatically restart system calls when > they are interrupted. We do under green_threads. The call to socketRead > calls sysRead which simply calls read on the correct fd. So if a signal > interrupts the read call we end up setting nread to -1 and errno to > EINTR. > What is correct here? Should we be restarting system calls under > native_threads? Would this mess up JNI users who want to be interrupted? (I have seen the same exception when using green threads, but I am unable to make a reliable test case which shows the bug under green threads so this may be something else.) I think system calls should always be restarted. And if these exceptions are trown they should be InterruptedIOExceptions and not SocketExceptions with the string "Interrupted system call". It might be inconvenient for JNI users, but since not all operating systems support interrupting system calls they cannot rely on this behaviour anyway. Thanks, Mark ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
