Re: New socket code for win32

I have been running with this patch for a week now, and it is more
stable than what's in there now for me. So I think it's ready to go.

I have attached an updated socket.c file that changes the following:
* Corrects two incorrect comments
* Zeroes out the fd_sets in select at EINTR for consistency

//Magnus

>-----Original Message-----
>From: Magnus Hagander
>Sent: den 4 april 2004 22:08
>To: pgsql-patches(at)postgresql(dot)org
>Subject: [PATCHES] New socket code for win32
>
>
>Here's an attempt at new socket and signal code for win32.
>
>It works on the principle of turning sockets into
>non-blocking, and then
>emulate blocking behaviour on top of that, while allowing signals to
>run. Signals are now implemented using an event instead of APCs, thus
>getting rid of the issue of APCs not being compatible with "old style"
>sockets functions.
>
>It also moves the win32 specific code away from pqsignal.h/c into
>port/win32, and also removes the "thread style workaround" of the APC
>issue previously in place.
>
>In order to make things work, a few things are also changed in
>pgstat.c:
>
>1) There is now a separate pipe to the collector and the bufferer. This
>is required because the pipe will otherwise only be signalled in one of
>the processes when the postmaster goes down. The MS winsock code for
>select() must have some kind of workaround for this behaviour, but I
>have found no stable way of doing that. You really are not supposed to
>use the same socket from more than one process (unless you use
>WSADuplicateSocket(), in which case the docs specifically say that only
>one will be flagged).
>
>2) The check for "postmaster death" is moved into a separate select()
>call after the main loop. The previous behaviour select():ed on the
>postmaster pipe, while later explicitly saying "we do NOT check for
>postmaster exit inside the loop".
>The issue was that the code relies on the same select() call
>seeing both
>the postmaster pipe *and* the pgstat pipe go away. This does not always
>happen, and it appears that useing WSAEventSelect() makes it even more
>common that it does not.
>Since it's only called when the process exits, I don't think using a
>separate select() call will have any significant impact on how
>the stats
>collector works.
>
>
>
>Anyway. Here is a patch for review. The two files go in
>backend/port/win32/.
>
>Passes all regression tests expected (time and ordering ones still
>fails, pgstat works)
>
>//Magnus
>
>