Tom, you seem to know everything related to Postgres, so thanks for your time and answers. I'm blown away by your dedication and knowledge.
Regarding PQisBusy, and similar, even for "non-blocking" behaviour, you are essentially expecting the user to have their own event loop, and only invoke the relevant libpq functions when I/O is actually possible, right?
e.g. in many cases, you'd set the socket to be non-blocking, and then just return to the user "I want to read more data".
What's actually stopping the implementation calling read/write directly? In the blocking case, that's correct behaviour. In the non-blocking case, I don't see how it's helpful to use epoll, because you should just return to the user right away.
Thanks
Samuel
On Sun, 31 Mar 2019 at 03:17, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Samuel Williams <space.ship.traveller@xxxxxxxxx> writes:
> I've been doing some profiling and I was surprised to see that libpq uses
> epoll when handling what essentially amounts to blocking reads/writes.
Yup.
> I was just wondering why it needed to be so complicated?
So that we can also support nonblocking behavior (cf PQisBusy).
If the library were being written from scratch today, I doubt anybody
would bother with that; it'd make more sense for an application to
use a separate thread for the database interaction, if there were
other things it needed to pay attention to concurrently. But it is
what it is.
regards, tom lane
