RE: WL_SOCKET_ACCEPT fairness on Windows

On Sat, April 1, 2023 at 11:00 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
Hi,
Thanks for your patch.

I tried to test this patch on Windows. And I did cover the new code path below:
```
+ /* We have another event to decode. */
+ cur_event = &set->events[next_pos + (rc - WAIT_OBJECT_0)];
```

But I have one thing want to confirm:
In my tests, I think the scenario with two different events (e.g., one ending
socket connection and one incoming socket connection) has been optimized.
However, it seems that when there are multiple incoming socket connections, the
function WaitEventSetWaitBlock is called multiple times instead of being called
once. Is this our expected result?

Here are my test details:
I use the debugger to ensure that multiple events occur when the function
WaitEventSetWaitBlock is called. First, I added a breakpoint in the below code:
```
/*
* Sleep.
*
* Need to wait for ->nevents + 1, because signal handle is in [0].
*/
b rc = WaitForMultipleObjects(set->nevents + 1, set->handles, FALSE,
cur_timeout);
```
And then make sure that the postmaster process enters the function
WaitForMultipleObjects. (I think the postmaster process will only return from
the function WaitForMultipleObjects when any object is signaled or timeout
occurs). Before the timeout occurs, I set up multiple socket connections using
psql (the first connection makes the process returns from the function
WaitForMultipleObjects). Then, as I continued debugging, multiple socket
connections were handled by different calls of the function
WaitEventSetWaitBlock.

Please let me know if I am missing something.

Regards,
Wang wei