[Spread-users] [BUG][PATCH] fd to session troubles
Ben Laurie
ben at algroup.co.uk
Mon Feb 4 05:43:03 EST 2002
Jonathan Stanton wrote:
>
> 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.
That's certainly how its supposed to work (with Unix, too).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
More information about the Spread-users
mailing list