Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events
От | Jacob Champion |
---|---|
Тема | Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events |
Дата | |
Msg-id | CAOYmi+n1xRNCDnwZzigXVk8V=+sr7ZzuGpJ0tAyozX-zQT19Gg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events
|
Список | pgsql-hackers |
On Wed, Aug 6, 2025 at 8:04 AM Thomas Munro <thomas.munro@gmail.com> wrote: > * If it returns 1, then it stopped on the first level-triggered event > that it rechecked and found to be still true. Who cares if there are > more that didn't get rechecked? poll(fd) will report POLLIN either > way, and that's what you want. I think the weaker guarantee might be sufficient. I was trying to get a stronger primitive in place so that we wouldn't have to worry about it down the line, but it is a lot of code to pay... One sharp edge of that strategy is caught by the new tests, which is that if you call drain_socket_events() and then unset the timer, your multiplexer is still readable until you call drain_socket_events() yet again. At the moment, our code only ever calls those two in the opposite order (due to the race condition pointed out in 0002); we'd just have to keep that in mind. Maybe "drain" would no longer be the verb to use there. --Jacob
В списке pgsql-hackers по дате отправления: