Event-driven, non-blocking I/O with PHP.

I fully expect that this PR will be rejected in its current form, but I needed a place to start a discussion about it.

This pull-request attempts to provide a reliable way to register callbacks on the event-loop that are executed with the following guarantees:

On each tick of the engine:

• the callbacks are executed in the same order as they are enqueued
• the callbacks are executed before any pending timer or IO events
• callbacks registered within an existing callback will also execute before IO events

As best I can tell this matches the current behaviour of process.nextTick() in nodejs (0.10.x), and as such I have dared to call the feature 'nextTick'. Please correct any misconceptions I have about this :) (see #92)

There is one new interface:

• NextTickLoopInterface - adds the nextTick() method to the existing LoopInterface

And two implementations:

• ExtEventLoop - uses ext-event (OOP bindings for libevent, see #161)
• StreamSelectNextTickLoop - a stream_select() based loop

Both implementations are tested against the existing abstract test cases for loops and timers.

I haven't had a chance to try libev or libuv yet, but I will attempt to provide implementations based on both of those libraries if this PR is well received.

I chose not to completely replace the existing stream_select() based loop at this stage, but there is no reason it would need to remain if the implementation proposed in this PR is accepted in the future.

Finally, I also added some doc-blocks to LoopInterface to clarify the guarantees made in regards to timer behaviour (in contrast to nextTick() behaviour) and return values.

Edit: Notably absent is any concept of minimum resolution for timers, I was speaking with @nrk about this on IRC and we talked about the possibility of allowing users to configure the resolution, perhaps that is now unnecessary.

This is just a proposal. And no unit-test code is available now.

Please give me advices for...

• Better API
  • Should the constructor param of Process be Stream object or resource variable?
• Better naming
  • Factory? Executor?
• Better implementation
• ..and so on

Below is the result of example code

$ php examples/child-process.php 
[A] [PID]    pid is 68466
[A] [CMD]    php '-r' 'foreach (range(1, 3) as $i) { echo $i, PHP_EOL; sleep(1); } fputs(STDERR, "Bye.");'
[B] [PID]    pid is 68467
[B] [CMD]    php '-r' 'foreach (range(1, 6) as $i) { echo $i, PHP_EOL; sleep(1); } fputs(STDERR, "Bye.");'
[C] [PID]    pid is 68468
[C] [CMD]    php '-r' 'foreach (range(1, 9) as $i) { echo $i, PHP_EOL; sleep(1); } fputs(STDERR, "Bye.");'
[C] [STDOUT] string(2) "1\n"
[A] [STDOUT] string(2) "1\n"
[B] [STDOUT] string(2) "1\n"
[A] [STDOUT] string(2) "2\n"
[B] [STDOUT] string(2) "2\n"
[C] [STDOUT] string(2) "2\n"
[A] [STDOUT] string(2) "3\n"
[C] [STDOUT] string(2) "3\n"
[B] [STDOUT] string(2) "3\n"
[B] [STDOUT] string(2) "4\n"
[C] [STDOUT] string(2) "4\n"
[A] [STDERR] string(4) "Bye."
[A] [STDOUT] string(0) ""
[A] [STDERR] string(0) ""
[A] [EXIT]   exited with status code 0
[B] [STDOUT] string(2) "5\n"
[C] [STDOUT] string(2) "5\n"
[B] [STDOUT] string(2) "6\n"
[C] [STDOUT] string(2) "6\n"
[B] [STDOUT] string(0) ""
[B] [STDERR] string(4) "Bye."
[B] [STDERR] string(0) ""
[B] [EXIT]   exited with status code 0
[C] [STDOUT] string(2) "7\n"
[C] [STDOUT] string(2) "8\n"
[C] [STDOUT] string(2) "9\n"
[C] [STDERR] string(4) "Bye."
[C] [STDOUT] string(0) ""
[C] [STDERR] string(0) ""
[C] [EXIT]   exited with status code 0

Currently, empty string is emitted when a process is exiting. It seems because of implementation difference of Stream->handleData() and Connection->handleData().

https://github.com/react-php/react/blob/2a43233661bd148c3eaa9214a89558669d202828/src/React/Socket/Connection.php#L14 https://github.com/react-php/react/blob/2a43233661bd148c3eaa9214a89558669d202828/src/React/Stream/Stream.php#L114

Connection->handleData() closes when hendled empty string and not emits data event then. But Stream->handleData() emits empty string.

What is the difference for?

Took @chobie's implementation of libuveventloop Implemented libuvfilesystem

ISSUE:

removeStream() fails, since libuv doesn't handle streams the same way libev does. You cannot open two streams on one input, it's only one stream with different flags. So, these lines

        $this->loop->addReadStream($input, $this->expectCallableOnce());
        $this->loop->addWriteStream($input, $this->expectCallableOnce());

basically come to calling:

• uv_poll_init() to init a stream.
• uv_poll_start() with UV::READABLE flag to start a read stream
• uv_poll_start() with UV:WRITABLE flag to start a write stream.

The matter is that addReadStream()'s callback never gets called.

People from libuv's IRC channel suggested me to use uv_stop(), in this way:

• uv_poll_init() to init a stream.
• uv_poll_start() with UV::READABLE flag to start a read stream
• uv_poll_stop() to stop the stream, while making sure to save the flags from current poll
• uv_poll_start() with both UV::WRITABLE and UV::READABLE flags to start a new read/write stream.

But the issue's still here, since addReadStream()'s callback still never gets called.

What should I do about it ?

This adds a very simple HTTP client implementation (1.0; no keep-alive, no chunked encoding)

Fixes #58

Usage example:

<?php

$loop = React\EventLoop\Factory::create();

$dnsResolverFactory = new React\Dns\Resolver\Factory();
$dnsResolver = $dnsResolverFactory->createCached('8.8.8.8', $loop);

$factory = new React\HttpClient\Factory();
$client = $factory->create($loop, $dnsResolver);

$request = $client->request('GET', 'https://github.com/');
$request->on('response', function ($response) {
    $response->on('data', function ($data) {
        // ...
    });
});
$request->end();

Travis CI added hhvm as possible PHP version to test against. Because hhvm is an emerging alternative PHP VM it's interesting to keep an eye on it. By adding it to the test matrix we can see how our code (changes) respond on hhvm. Since it's not critical and AFAIK a goal to work on hhvm I've added it to allow failures. So we don't have to worry about breaking the tests if it doesn't work in hhvm just yet.

ATM, ReactPHP has IRC as the official communication channel.

From my point of view, if we want to increase this community, which in fact should be insane, we should try to transform this community in order to be more easy for the people to ask, respond and solve problems. Otherwise, frustration is what people have, and this is usually synonym to "bounce rate".

I can understand that some people don't like Slack because is not open source, but as far as I see, Slack communities are, at this precise moment, the most growing communities. That could help a lot ReactPHP to start growing as it deserves.

This is my proposal. Let the discussion start :D

I'm writing a small application using React and Ratchet that opens up a few long-running external processes, and redirects some of their output (via stdout) through a websocket connection.

Using popen and React's stream class to talk to the external process usually works just fine, and the process's output gets sent to the websocket as it executes -- as one would expect. Some processes, however, block the event loop until they've completed running.

Inside my Ratchet application, I can run

$ping = new Stream(popen("ping -t 127.0.0.1",'r'),$server->loop);
$ping->on('data',function($data) use ($from){
    $from->send($data);
});

and ping will continuously direct its output through my websocket connection, $from.

However, if I use a different executable (in this case, the Adobe F4V Post-Processor), I get no output from f4vpp, or anything else in my event loop (say, the ping command above) until f4vpp exits.

$f4vpp = new Stream(popen("f4vpp -v -i in.f4v -o out.mp4",'r'),$server->loop);
$f4vpp->on('data',function($data) use ($from){
    $from->send($data);
});

What's going on here? Is this user error, or a legitimate shortcoming in React or PHP on win32?

PHP 5.4.0 was released on 01-Mar-2012. The end of life for PHP 5.3.x is in March 2013.

The major decision factor is a) ease of getting started; b) ease of deployment.

Getting started

In case users do not have PHP 5.4.x on their local machines, we must provide install instructions. For example, OSX ships with 5.3, so we should point users to either php-osx or homebrew-php.

This seems like an acceptable requirement to me.

Deployment

It is critical that major distros ship with PHP 5.4 before we bump the requirement.

• Ubuntu and Fedora are already doing so.
• Debian will ship with it in the next release. Which will be around Feb/Mar 2013.
• I wasn't able to find any info on Centos and RedHat.

Proposal

IMO we should wait at least until debian wheezy is out. Which would mean bumping whenever that happens, hopefully within the next 2-3 months.

Feedback please.

This PR is based on PR #41. Fixes #19.

TODO:

• Benchmark and profile
• Set up subtree split

References:

• RFC1034 Domain Names - Concepts and Facilities
• RFC1035 Domain Names - Implementation and Specification

Port the mongrel http parser to PHP. Or maybe the node one.

Also provide adapters for PHP extensions:

• httpparser-php (mongrel)
• php-httpparser (node)

Creating a temporary error handler when selecting/accepting a stream to avoid warning messages, caused by catching a signal with function pcntl_signal().

See issue : https://github.com/reactphp/react/issues/296

We should make some revisions about the blog posts and the talks in the main repository README file. For example, the "Super Speed Symfony - ReactPHP" is more than 3 years old, and is based on top of old versions for both Symfony and ReactPHP libraries.