Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> Agreed. Seems like the best answer is to get in bed with the Windows
>> representation of fd_set, since we cannot avoid knowing that it is
>> different from other platforms' versions. I suggest that we might as
>> well get all the way in and dodge the FD_SETSIZE limitation altogether,
>> as per the attached utterly-untested draft patch.
> ISTM that the patch your propose, a full reimplementation of the abstract
> poll/select fd set interface for windows, is overkill because it adds
> about 80 lines of code. ISTM that just redefining some macros is enough to
> get the same performance benefit without adding much to the code base, but
> maybe I'm missing something. At least, I do not think that getting rid of
> the FD_SETSIZE redefinition for windows is worth all that trouble.
I think it's worth doing because it puts the Windows implementation at
full feature parity with Unixen, ie, there's no hard-wired limit on the
number of connections. I'm also not that thrilled with trying to make
one code path work with two fundamentally different implementations.
We've found out that just because Microsoft claims their implementation
is compatible with POSIX doesn't make it so, and I'd rather not have
warts in our source code from trying to paper over that.
Lastly, I think it's entirely likely that someone will come up with a
Windows-native implementation at some point, so that we'd have the extra
code lines anyway.
regards, tom lane