public inbox for [email protected]
help / color / mirror / Atom feedFrom: Thomas Munro <[email protected]>
To: Dominique Devienne <[email protected]>
Cc: [email protected]
Subject: Re: libpq v17 PQsocketPoll timeout is not granular enough
Date: Tue, 11 Jun 2024 10:59:28 +1200
Message-ID: <CA+hUKGKgvN=jjCcTtfEHiyiWkivgz1POLe2GPbeDPajZGkF_Ew@mail.gmail.com> (raw)
In-Reply-To: <CAFCRh-8hf=7V8UoF63aLxSkeFmXX8-1O5tRxHL61Pngb7V9rcw@mail.gmail.com>
References: <CAFCRh-8hf=7V8UoF63aLxSkeFmXX8-1O5tRxHL61Pngb7V9rcw@mail.gmail.com>
On Tue, Jun 11, 2024 at 2:36 AM Dominique Devienne <[email protected]> wrote:
> Hi. I've noticed [that libpq API in v17 beta1][1], and wanted to use
> it to replace an existing Boost.ASIO-based async polling of the
> connection's socket, waiting for notifications. The use case being
> using PostgreSQL LISTEN/NOTIFY for a simple message queue. The code
> needs to be cross-platform Windows and Linux. My goal would be to
> eliminate that Boost.ASIO dependency for that, to use just libpq.
One idea I have wondered about is why you wouldn't just use poll()
directly, if you want a facility that works on all known operating
systems without extra portability libraries. Windows has WSApoll(),
which AFAIK was designed to be Unix-compatible and a drop-in
replacement, requiring just a rename but otherwise having the same
macros and struct etc.
For some period of time, people who had to deal with socket connection
events (that includes us) avoided it, with the Curl guys' blog being
the most often cited public explanation for why:
https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
However, as far as I know, that was fixed ~4 years ago:
https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll
"Note As of Windows 10 version 2004, when a TCP socket fails to
connect, (POLLHUP \| POLLERR \| POLLWRNORM) is indicated."
I wonder if that means that it's now completely usable on all
reasonable versions of the OS. I think so? I don't use Windows
myself, my interest in this topic is that I have a slow moving
background project to figure out how and when to remove all remaining
uses of select() from our tree, and this one is on my hit list.
> PQsocketPoll() being based on time_t, it has only second resolution, AFAIK.
> Despite the [underlying implementation in fe-misc.c][2] supporting at
> least milliseconds.
Yeah, that is not nice and your complaint is very reasonable, and we
should probably do something like what Tom suggested.
Hmm, but if what I speculated above is true, I wonder if the extern
function is even worth its bits... but I don't know how to determine
that completely.
view thread (4+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: libpq v17 PQsocketPoll timeout is not granular enough
In-Reply-To: <CA+hUKGKgvN=jjCcTtfEHiyiWkivgz1POLe2GPbeDPajZGkF_Ew@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox