[Spread-users] [BUG][PATCH] fd to session troubles

[Jonathan Stanton]

On Fri, Jan 25, 2002 at 02:11:46PM -0500, Tim Peters wrote:
> Good catch!  The "Windows bug" comment is incorrect, because sockets simply
> aren't fds on Windows (or BeOS) -- they're a distinct datatype.  The handle
> that represents a socket on Windows comes out of a handle space whose upper
> bound cannot be predicted in advance.  FD_SETSIZE on Windows is simply the
> maximum number *of* socket handles you can pass to the Windows select.
> 
> Spread could also boost FD_SETSIZE on Windows (it's OK to #define this
> yourself on Windows, before #include'ing winsock.h (in Python, we boost it
> to 512 by default)), but there remains no relation between FD_SETSIZE and
> the numerical magnitude of Windows socket handles.  An fd_set on Windows is
> a contiguous vector of socket handles, not a bit map as on Unix:
> 
> /* This is from winsock.h */
> typedef struct fd_set {
>         u_int   fd_count;               /* how many are SET? */
>         SOCKET  fd_array[FD_SETSIZE];   /* an array of SOCKETs */
> } fd_set;

So you are saying if we add a line 
#define FD_SETSIZE 1024 

in the Windows section of our arch.h, then windows select will work with
1024 sockets at once? I just want to verify it because it seems like the
windows libc/equivelent might have it's own compiled in knowledge of the
size of the fd_set struct and think it is only 64. 

The way I can imagine this working, is that the libc just looks at fd_count
and trusts that the fd_array array is big enough to hold all the sockets
the apps says are in it.  If it isn't, then that is the application's fault
and the app will crash (ok), but as long as the app is ok, then the system
is as well.

Thanks,

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------