fix for socket timeouts (and a question about _Jv_select)

Fri Jun 29 18:54:00 GMT 2001

I've fixed the socket timeout problems... 
It was pretty simple really, just hacking the read and write funcs
from natFileDescriptorPosix.cc into the natPlainSocketImpl.cc. Most of
the work was already done in the FD class.
In fact, the hardest part was working out how to get everything to
compile and install again, but even that didn't take that long.
Some questions:
I haven't added support for WinSock yet. Can someone confirm if I
need to?
I hope I can contribute this back to you guys... do I need to liase
with the FSF over (c) forms or is someone on the project handling it?
How do you want the changes? Will a diff between 3.0 cvs and the
changed files in my working dir be okay? (I've no idea how to generate
a patch).
There is one problem with the current code. It's an issue in the
existing natFileDescriptorPosix and natPlainSocketImpl and it's to do
with how select() is called.
posix.cc defines _Jv_select like this:
 int _Jv_select (int n, fd_set *readfds, fd_set *writefds,
	 fd_set *exceptfds, struct timeval *timeout)
it calls select in the way you'd expect, ie:
 int result=select(n, readfds, writefds, exceptfds, timeout);
But I can't understand the way it's called in natFileDescriptorPosix
and natPlainSocketImpl because in those files 'n' is set to the socket
number, the calls do this:
 int fd=...; //the file descriptor obtained from the call to open
 .
 .
 .
 //inside a method
 int result=_Jv_select(fd+1,&fds,NULL,NULL,timeout);
 .
 .
 .
This would seem to be ridiculous! I don't see how using the
filedescriptor number +1 could ever be the correct value of 'n' in a
call to select.
Indeed, I ran a test and the number being passed in (on my test) was
8. But it should be 1! no?
The value of 'n' should be the number of filedescriptors that select
is being asked to scan. In this case: 1.
Can someone please tell me if I'm missing something really obvious?
Nic