Recoil asynchronous framework

[CMCDragonkai]

What's the difference between using ReactPHP by itself and using Recoil? If I was building a new asynchronous application, would I put Recoil on top of ReactPHP? What kind of advantages does it provide?

[jmalloc]

I've struggled to explain this well, I'll do my best :)

I should start by saying two things:

• Recoil is all about syntax; anything you can achieve with Recoil could be done with React alone.
• Recoil adds overhead, an equivalent system written directly in React will be faster.

What Recoil tries to do is to make writing asynchronous code "feel" like synchronous code. If you're familiar with asynchronous IO and/or apps based on the reactor pattern (be it via React, NodeJS, boost::asio, whatever), you'll also be familiar with passing callbacks around to receive results from asynchronous operations, this often means not being able to use return values and having to explicitly check for error conditions, etc. Recoil uses PHP generators, specifically their ability to suspend and resume execution as the 'break points' where code can wait for asynchronous events to occur, rather than having to provide a callback.

This example, which uses Recoil to asynchronously/concurrently resolve some domain names can be compared to this one, which is equivalent but uses React DNS and promises directly. Note specifically the control flow and the way in which errors are reported. I like to think that (except for the yield keyword) the Recoil example is more or less what equivalent synchronous code would look like.

Hopefully these examples help make some sense of the idea behind Recoil. It's by no means original, but I think Recoil is the first 'full featured' implementation for PHP... whatever that might mean :) If you've got the time, this article by @nikic is an excellent walkthrough of a system with the same underlying idea as Recoil. Of course, please feel free to ask further questions right here.

[CMCDragonkai]

I just read through the long article by Nikic. I'll need to look into it deeper later. But some questions came to mind:

1. Wouldn't this be slower than preemptive multitasking using threads such as pthreads (due to userland code and the constant jumping between the scheduler and the tasks)? Multithreading seems directly the most comparable.
2. Would this work in HHVM? I noticed that hhvm supports xbox messaging for multithreading purposes. But no pthreads support. I suggest adding hhvm to the travis.yml.
3. With regards to syntax, this coroutines could be worked into promises? Or should they be separate. When would one use coroutines and not use promises and use promises but not coroutines. (I see the section on PromiseCoroutines)

The only thing stopping me from fully committing to async frameworks is usually the ecosystem of tools that PHP built up are by majority not asynchronous. There's yet to be an ORM like Doctrine or Propel that's asynchronous. Hopefully this could help.

Just in the question of reactor patterns in general. It seems most reactor patterns are single threaded, are there implementations which try to do reactor patterns that are inherently multithreaded?

[jmalloc]

1. To be honest I'm not very familiar with pthreads. As I understand it, it doesn't let you share resources between threads (it clones objects that you pass to new threads, etc) and obviously creates a kernel-level thread as well, so thread creation still has the same overhead as it would in other languages. There's a very good chance I'm wrong about this, I need to learn more about pthreads myself. If there is a benefit to giving Recoil some kind of explicit support for pthreads I'd be happy to do so.
2. I can't think of any reason it shouldn't work under HHVM. React does and Recoil doesn't do anything especially fancy. The only thing holding me back on this is that some of our tooling doesn't yet run under HHVM (notably the mocking framework Phake. I did create Add HHVM to Travis config. phake/phake#133 to get the ball rolling, but we'll probably end up finding another framework, or going back to PHPUnit's own mocking system.
3. In some regards coroutines are a higher-level abstraction than promises. Recoil is written such that the two can interact, mainly so that promise-based APIs written for React work nicely from inside coroutines. So I guess to answer the question I would say simply to use coroutines when writing something intended to run with Recoil, otherwise use promises.

You're absolutely right about the fact that the majority of tools for PHP are not asynchronous, furthermore, even if they were they need to target the same reactor implementation (eg, React) to be used together. For what it's worth, I'm trying to get an asynchronous PDO-like abstraction happening here. It's not 100% complete, but it works and could serve as a basis for an ORM implementation in the asynchronous world. I think I will probably change this library to be written using promises so that it can work directly with React.

The only reactor implementation I know of that has explicit support for threads is Boost.Asio for C++, see here and here, note also that what Asio refers to as 'strands' is somewhat different to a 'strand' in Recoil.

[CMCDragonkai]

One thing to note with regards to multithreading. Is that coroutines will always be bound to 1 logical cpu core. So you can't take advantage of true parrallelism.

[jmalloc]

Possibly relevant to your interests : https://gist.github.com/krakjoe/6437782/

[CMCDragonkai]

Yep I know about that and have considered pthreads. However the problem is that it relies on a specific compiled version of PHP.

[CMCDragonkai]

Have you seen swoole https://github.com/matyhtf/swoole It looks very interesting. Perhaps recoil could be integrated in Swoole?