Non-Blocking PostgreSQL

From: Date: Mon, 13 Jan 2014 13:52:31 +0000
Subject: Non-Blocking PostgreSQL
Groups: php.internals 
Request: Send a blank email to internals+get-71109@lists.php.net to get a copy of this message
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!

« previous php.internals (#71109) next »