Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
In-Reply-To: <CAH8Mpnn=FnyXyaYts_KiysRzXQ5ofMCr4gf_XNQqKt8bW-ASTw@mail.gmail.com>
References: <CAH8Mpnn=FnyXyaYts_KiysRzXQ5ofMCr4gf_XNQqKt8bW-ASTw@mail.gmail.com>
Date: Tue, 14 Jan 2014 00:50:16 +0100
Message-ID: <CALJZF3g+Ks82q5aamFWhbRhtj6-9scVW=FGZDxQA7EMHRJK=eA@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11345896d0b8ed04efe2bcbf
Subject: Re: [PHP-DEV] Non-Blocking PostgreSQL
From: mike@php.net (Michael Wallner)

--001a11345896d0b8ed04efe2bcbf
Content-Type: text/plain; charset=UTF-8

On 13 Jan 2014 14:52, "Daniel Lowrey" <rdlowrey@gmail.com> wrote:
>
> 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!

Check this out whike you're st it: http://pecl.php.net/package/pq

--001a11345896d0b8ed04efe2bcbf--