From: Godmar Back (gback@cs.utah.edu)
Date: Thu Feb 11 1999 - 18:15:42 EST
Tim,
>
> Well ... if you don't have EAGAIN (or EWOULDBLOCK since they're the same) in
> jthreadedTimedRead then when read returns EAGAIN more than once (and this appears to
> happen) it will timeout - even though it doesn't actually timeout (because the
> timeout is zero).
You are right that we should not return the second time we get EAGAIN if
the time out value passed in is zero. In this case, we could safely ignore
the spurious wakeup and go back to sleep if read return EAGAIN the second
time.
This, however, assumes that we weren't resumed via an explicit call to
resumeThread, as would be caused by Thread.interrupt();
We will need an additional flag to ensure a thread who gets interrupted via
Thread.interrupt() wakes up and returns from read() with EINTR, causing an
InterruptedIOException().
> It would appear that the socket becomes ready even when their's
> nothing to read (possibly because the connection has been made but no data sent).
> You may be right that the timeout never works with my fix (checking now) but some
> kind of fix is required here.
But that's a bug in Linux, isn't it?
If I successfully select on a socket, I should never get an EAGAIN/EWOULDBLOCK
on a subsequent read().
Btw, I've seen people work around getting unwanted InterruptedIOExceptions
for UDPSocket in Blackdown's port with code like
for(;;) {
try {
socket.receive()
return;
} catch (IOException e) {
/* ignore */
}
}
>
> .. time passes ...
>
> Your right that soTimeout fails and throws a null pointer exception ....
>
> Perhaps block on file should return true/false depending on whether it timed out or
> not?
>
The way a caller recognizes whether a call to timed_read() timed out
or not is by checking the return value.
If the return value == EINTR, then it timed out or was interrupted via
Thread.interrupt(). Either way, an InterruptedIOException is thrown.
If the return value == 0, the read was successful (can mean eof depending
on how many bytes were read.)
If the return value is != 0 && != EINTR, it's an error.
Note that timedread can never really fail because of EINTR, that's why
I thought it was safe to use EINTR for the meaning "timed out" or "was
interrupted".
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:06 EDT