7

I am reading libpq reference. It has both of sync and async methods. Bu I discovered something strange.

When I see PQsendQuery function, it seems to send a query and return immediately. And I expected a callback function to get notified, but there was no such thing and the manual says to poll for data availability.

I don't understand why async method is written in polling way. Anyway, as libp is the official client implementation, I believe there should be a good reason for this design. What is that? Or am I missing correct callback stuffs mentioned somewhere else?

eonil
  • 83,476
  • 81
  • 317
  • 516
  • 3
    Just a note for later: `libpq` has `PQsocket` function which returns *file descriptor* for the socket. To be notified for data availability, monitor this socket using system API. (`kqueue`, `libdispatch` or etc.) – eonil Oct 16 '13 at 14:26
  • 2
    Now I finally understood this design. This is just difference of blocking vs non-blocking *style*, and form of API really doesn't matter on performance stuff. – eonil Dec 03 '14 at 12:04

2 Answers2

6

In the execution model of a mono-threaded program, the execution flow can't be interrupted by data coming back from an asynchronous query, or more generally a network socket. Only signals (SIGTERM and friends) may interrupt the flow, but signals can't be hooked to data coming in.

That's why having a callback to get notified of incoming data is not possible. The piece of code in libpq that would be necessary to emit the callback would never run if your code doesn't call it. And if you have to call it, that defeats the whole point of a callback.

There are libraries like Qt that provide callbacks, but they're architectured from the ground up with a main loop that acts as an event processor. The user code is organized in callbacks and event-based processing of incoming data is possible. But in this case the library takes ownership of the execution flow, meaning its mainloop polls the data sources. That just shifts the responsibility to another piece of code outside of libpq.

Daniel Vérité
  • 58,074
  • 15
  • 129
  • 156
  • It seems `libpq` is designed for single-threaded program. Is it fine for performance? – eonil Oct 14 '13 at 06:26
  • 3
    @Eonil: Any network client would have to wait on sockets. `libpq` simply exposes that to the library user, making it possible to use `libpq` with existing event libraries, such as `libevent` or Linux `epoll`. That makes `libpq` much more scaleable than it would have been with a blocking client (e.g. http://www.kegel.com/c10k.html#threaded), not wasting threads waiting and waiting on the database. So yes, it's very good for performance. – ArtemGr Dec 01 '13 at 11:23
-1

This page is describing how I can get be notified for async result fetch.

http://www.postgresql.org/docs/9.3/static/libpq-events.html#LIBPQ-EVENTS-PROC

PGEVT_RESULTCREATE

The result creation event is fired in response to any query execution function that generates a result, including PQgetResult. This event will only be fired after the result has been created successfully.

typedef struct { PGconn *conn; PGresult *result; } PGEventResultCreate; When a PGEVT_RESULTCREATE event is received, the evtInfo pointer should be cast to a PGEventResultCreate *. The conn is the connection used to generate the result. This is the ideal place to initialize any instanceData that needs to be associated with the result. If the event procedure fails, the result will be cleared and the failure will be propagated. The event procedure must not try to PQclear the result object for itself. When returning a failure code, all cleanup must be performed as no PGEVT_RESULTDESTROY event will be sent.

eonil
  • 83,476
  • 81
  • 317
  • 516