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".
signature.asc
Description: Digital signature
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
