> > Under Win32, which specifically states of fd_sets "data
> representation
> > is opaque", I'd argue that it isn't strictly a good idea... but
> > clearly, by inspection of the Win32 fd_set type, it'll work
> (and would
> > clearly continue to do so for any sensible implementation
> of fd_sets),
> > so I have a pretty low care-factor... :-)
>
> I missed the reason for agonizing over fd_sets, but maybe you
> should be thinking about using poll() instead of select() anyway?
Definitly no poll() on win32 :-) But in the future we might want to use
a native method, yes. Probably something based on WSAEventSelect(). But
this is a much larger change to the backend code.
The reason we were talking about it was using memcpy() to copy them to a
different location. Looking at the header files (winsock.h specifically)
this is safe with the current implementation, and I doubt they can
change that since it'd break a lot of apps.
> select() is a bit risky since it can fail if the process has
> enough FDs open to exceed whatever the FD set size is --- you
> may be wishing to wait on an FD that can't be represented in
> an fd_set. This cannot happen in the postmaster, which never
> has more than a few files open, but for general-purpose use
> in backends I'd much rather see us use
> poll() on all platforms that have it. I assume Windows does...
The limit for select on win32 is actually 64, which is horribly low in
many cases. But as it is right now, select() is only used in the
postmaster and in the pgstat process, neither of which use any large
number of fds. Since we only select() on sockets, and not the files.
This can be raised by a simple #define, but talking to Claudio we
figured that shouldn't be necessary.
The only other place I see using select() as a possible is selecting on
a single socket in the general backend, for signal delivery.
//Magnus