Interesting. In my understanding this also needs to make Latch
frontend-friendly?
It could be refactored to support a different subset of event types --
maybe just sockets, no latches and obviously no 'postmaster death'.
But figuring out how to make latches work between threads might also
be interesting for future projects...
Maybe Fabien has completion-based I/O in mind (not just "readiness").
Pgbench is really a primitive client on top of libpq. ISTM that
completion-based I/O would require to enhance libpq asynchronous-ity, not
just expose its underlying fd to allow asynchronous implementations.
Currently pgbench only actuall "waits" for results from the server
and testing PQisBusy to check whether they are there.
That's something that some of those libraries can do, IIUC. For
example, when your thread wakes up, it tells you "your socket read is
finished, the data is already in your target buffer".
Indeed, libevent has a higher level "buffer" oriented API.
As opposed to "you can now call recv() without blocking", so you avoid
another trip into the kernel. But that's also something we'll
eventually want to figure out in the server.
--
Fabien.
