I committed this for 17. It would be good to come up with something
fundamentally better than this, to get rid of that 64 event limit
nonsense, but I don't see it happening in the 17 cycle, and prefer the
semantics with this commit in the meantime.
On Thu, May 18, 2023 at 8:53 PM Wei Wang (Fujitsu)
wrote:
> On Sat, April 1, 2023 at 11:00 AM Thomas Munro wrote:
> 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-
On Sat, April 1, 2023 at 11:00 AM Thomas Munro 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)];
Hi,
On 2023-05-17 08:41:24 +1200, Thomas Munro wrote:
> Yeah. No one seems to think this is worth worrying about (please
> speak up if you do).
+1 - we have much bigger fish to fry IMO.
Greetings,
Andres Freund
On 5/16/23 4:41 PM, Thomas Munro wrote:
On Wed, May 17, 2023 at 2:57 AM Jonathan S. Katz wrote:
Given this has sat for a bit, I wanted to see if any of your thinking
has changed on whether this should be fixed for v16 or v17. I have
personally not formed an opinion yet, but per the current di
On Wed, May 17, 2023 at 2:57 AM Jonathan S. Katz wrote:
> On 3/31/23 11:00 PM, Thomas Munro wrote:
> >>> I mention this now because I'm not sure whether to consider this an
> >>> 'open item' for 16, or merely an enhancement for 17. I guess the
> >>> former, because someone might call that a new d
On 3/31/23 11:00 PM, Thomas Munro wrote:
I mention this now because I'm not sure whether to consider this an
'open item' for 16, or merely an enhancement for 17. I guess the
former, because someone might call that a new denial of service
vector. On the other hand, if you fill up the listen que
On Sat, Apr 1, 2023 at 2:35 PM Andres Freund wrote:
> I wonder if we ought to bite the bullet and replace the use of
> WaitForMultipleObjects() with RegisterWaitForSingleObject() and then use
> GetQueuedCompletionStatus() to wait. The fairness issue here is a motivation,
> but the bigger one is th
Hi,
On 2023-04-01 13:42:21 +1300, Thomas Munro wrote:
> Commit 7389aad6 started using WaitEventSetWait() to wait for incoming
> connections. Before that, we used select(), for which we have our own
> implementation for Windows.
>
> While hacking on patches to rip a bunch of unused Win32 socket w
