Search Mailing List

Jann Horn jann+libev at thejh.net
Tue Jul 9 12:22:56 CEST 2013


You might want to choose a better subject for your mail next time.

On Mon, Jul 08, 2013 at 02:28:18PM -0500, Justin Tocci wrote:
> I'm having trouble finding answers to my questions.
> I'm looking for an example of a call to Postgres' async interface, libpq(PQsendQuery/PQgetResult).
> 
> Example Google searches that return no results:
> ev_async PQsendQuery
> ev_run PQsendQuery
> ev_run PQgetResult
> PQgetResult site:lists.schmorp.de/pipermail/libev/
> 
> Consequently, I'm inclined to conclude that I'm trying to do something I am not supposed to do.

How so? Why would you expect to find ready-made explainations for connecting arbitrary pieces
of software that would fit together? Just read the documentation for both pieces of software,
then figure out to connect them.


> I want to use ev_async and PQsendQuery/PQgetResult to replace this PSGI application. My questions are: 
> 
> Is Libev the appropriate tool for this or is there something better? (Why can't I find an example?)

Libev should work fine as a library for this, I think. Well, a threadpool would probably work fine, too.


> Is ev_async the proper watcher in this case?

No. You want ev_io.


> Can someone give me a three sentence explanation on how to go about this? (use x watcher, use idle for y, use a timer for z)

Probably not three sentences.
First, let's have a look at <http://www.postgresql.org/docs/8.4/static/libpq-async.html>:

| Applications that do not like these limitations can instead use the underlying functions that
| PQexec is built from: PQsendQuery and PQgetResult.
[...]
| PQgetResult
|   Waits for the next result from a prior PQsendQuery [...] call, and returns it.
[...]
| PQconsumeInput
|   If input is available from the server, consume it.
[...]
| PQisBusy
|   Returns 1 if a command is busy, that is, PQgetResult would block waiting for input. A 0 return
|   indicates that PQgetResult can be called with assurance of not blocking.
|   PQisBusy will not itself attempt to read data from the server; therefore PQconsumeInput must
|   be invoked first, or the busy state will never end.
[...]
| A typical application using these functions will have a main loop that uses select() or poll()
| to wait for all the conditions that it must respond to. One of the conditions will be input
| available from the server, which in terms of select() means readable data on the file
| descriptor identified by PQsocket. When the main loop detects input ready, it should call
| PQconsumeInput to read the input. It can then call PQisBusy, followed by PQgetResult if
| PQisBusy returns false (0).

select() or poll() (or another similar interface) is what an IO watcher is built on.

And now let's have a look at the libev documentation:
<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#code_ev_io_code_is_this_file_descrip>
| I/O watchers check whether a file descriptor is readable or writable [...]

So, combining this, after you've sent your query, you need an I/O watcher (ev_io) on the
file descriptor of the database connection (which you can get with PQSocket). And when that
watcher fires, you do everything that, according to the psql documentation, you should do "when the
main loop detects input ready".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20130709/19772732/attachment.sig>


More information about the libev mailing list