Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71109
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
Date: Mon, 13 Jan 2014 08:52:31 -0500
Message-ID: <CAH8Mpnn=FnyXyaYts_KiysRzXQ5ofMCr4gf_XNQqKt8bW-ASTw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae934100f15058b04efda63f4
Subject: Non-Blocking PostgreSQL
From: rdlowrey@gmail.com (Daniel Lowrey)

--14dae934100f15058b04efda63f4
Content-Type: text/plain; charset=ISO-8859-1

Hi, internals!

Since Yasuo mentiond ext/pgsql ...

The Postgres extension allows for some limited "async" functionality but it
simplifies things for users by blocking on socket writes and offers no
potential for asynchronous connection attempts. This makes the extension
unusable inside non-blocking event loops. Because non-blocking is pretty
much the only thing I do these days I spent a bit of time over the holidays
I to address these issues.

There is a fully-functioning implementation here that addresses all of my
needs:

https://github.com/rdlowrey/php-src/compare/pgsql-async

Some brief (simple) usage examples can be seen here:

https://gist.github.com/rdlowrey/8114597

I plan to add some tests and merge the changes for 5.6/master but I just
wanted to check to make sure no one has feedback/suggestions prior to doing
so.


A summary of changes:

- No BC breaks, compatible with very old libpq versions
- Several new functions mapping to PQ_* functions
- Expose the underlying socket via a new pg_socket($db) function. The
resulting stream has no behavior *except* to allow casting to a descriptor
for IO notifications via select/epoll/kqueue etc.
- Closing the exposed stream has no effect on the associated pgsql
resource. It's impossible to break the existing API using the exported
descriptor handle.
- Connections may now be established asynchronously as a result of
pg_socket(), pg_connect_poll() and newly exposed constants.
- This patch adds an optional boolean $shouldBlock=TRUE to the few methods
that currently block on writes to retain BC while allowing users to
manually manage IO in non-blocking environments.

-- New Functions --

- int pg_connect_poll(resource $pgsql)
- resource pg_socket(resource $pgsql)
- int pg_consume_input(resource $pgsql)
- int pg_flush(resource $pgsql)

-- Altered Functions --

Each of the existing "async" send methods now accept an optional boolean
$should_block = TRUE parameter to control the undesirable blocking send
behavior.

- pg_send_execute
- pg_send_prepare
- pg_send_query_params
- pg_send_query

-- New Constants --

- PGSQL_CONNECT_ASYNC
- PGSQL_CONNECTION_STARTED
- PGSQL_CONNECTION_MADE
- PGSQL_CONNECTION_AWAITING_RESPONSE
- PGSQL_CONNECTION_AUTH_OK
- PGSQL_CONNECTION_SSL_STARTUP
- PGSQL_CONNECTION_SETENV
- PGSQL_POLLING_FAILED
- PGSQL_POLLING_READING
- PGSQL_POLLING_WRITING
- PGSQL_POLLING_OK
- PGSQL_POLLING_ACTIVE

If anyone has any thoughts please let me know!

--14dae934100f15058b04efda63f4--