On Dec 4, 2006, at 11:19 AM, David Daney wrote:
Andrew Haley wrote:
Roman Kennke writes:
> > 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
If connect(2) returns EINTR, you should retry:
CPNIO_EXPORT int
cpnio_connect (int fd, const struct sockaddr *addr, socklen_t
addrlen)
{
int retcode;
do
{
retcode = connect (fd, addr, addrlen);
}
while (retcode == EINTR);
return retcode;
}
Except that you should probably also check if the thread was
interrupted as the original patch does for read and write.
Also, it occurs to me that VMChannel.connect should just use "select"
for all cases -- right now, if no timeout is specified, it relies on
connect(2) blocking. In other cases, the socket is put into non-
blocking mode, and the timeout is applied in a call to select. Using
select for all cases would clean up that function a lot.
This call to select also looks like it needs EINTR protection.
Thanks.
