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

Tim Peters tim at zope.com
Mon Feb 4 02:30:03 EST 2002


[Jonathan Stanton]
> Thanks for the info and checking it out. I appreciate it.

My pleasure!  I suffer Windows so my coworkers don't have to <wink>.

> I've added the 1024 #define into the CVS tree for the 3.16.2 release.

Cool.  You won't regret it -- it's a good change.

> It seems hard to imagine some of the people needing production windows
> boxes only needing 64 sockets at once...

Many default limits in Windows are historical remnants preserved for strict
backward compatibility.  64 "looked real big" in its day.  Everyone
redefines FD_SETSIZE higher now, so end users rarely notice it.  Developers
trip each other up, though, via conflicting redefinition of FD_SETSIZE.
That's why, e.g., Python boosts it to 512 only if FD_SETSIZE isn't already
defined, and even then only in a file that people writing to the Python C
API don't normally see.  A saving grace of the Windows design is that
multiple modules can each believe something different about what FD_SETSIZE
"actually is", just so long as they don't pass fd_sets among each other.

> Hopefully with this set of changes Spread will be more useful on Windows.

Frankly, it's enough for our purposes if it simply doesn't crash <wink>, and
we've had very good luck with that after fiddling the source to close
sockets on Windows.  The app we're building is targeted for Linux; the real
value of running on Windows too is that process and thread scheduling vary
so much between these OSes that testing on Windows turns up races that can
be very hard to provoke on Linux, and vice versa.  We've seen the same truth
repeatedly in a decade of Python development:  testing on both platforms can
drive you nuts, but it catches legitimate race bugs much quicker than
testing on only one.  Ditto, e.g., testing on both Linux and Solaris
(Windows loves threads and is generally most eager to switch threads
frequently, Solaris least, and Linux somewhere in the middle; OTOH,
processes take approximately forever to create on Windows; etc; this wild
mix is effective at unrooting bad assumptions).






More information about the Spread-users mailing list