Обсуждение: libpq read/write
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.
https://github.com/postgres/postgres/blob/fc22b6623b6b3bab3cb057ccd282c2bfad1a0b30/src/backend/libpq/pqcomm.c#L207-L227
I was just wondering why it needed to be so complicated?
What's wrong with just using read/write when blocking semantics are desired? You can still restart them if they are interrupted (might not be desired default behaviour). The problem is, it's hard for me to measure "blocking" time when libpq uses epoll rather than blocking read/write.
I guess I'm not expecting to rewrite it or anything, just wondering why it's designed that way.
Kind regards,
Samuel
Samuel Williams <space.ship.traveller@gmail.com> 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
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@sss.pgh.pa.us> wrote:
Samuel Williams <space.ship.traveller@gmail.com> 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