Future plans for this package

[kelunik]

Hey,

what are the future plans for this package, given you have integrated amphp/parallel-functions into https://github.com/spatie/laravel-collection-macros instead of using this package?

Generally I'd recommend against using forks, because each forks retains the previous state, e.g. open files etc. While that's currently also true for all child processes opened by PHP, that might change in the future, and they're already better for most uses generic use cases right now, because they don't retain the memory allocated by the currently running process.

[brendt]

Hey @kelunik

We're actually going to move away from pcntl_fork and use symfony/process instead. We'll also be using signals instead of sockets for IPC. A work-in-progress implementation can be found here: https://github.com/spatie/async/tree/symfony-process.

Note that we don't see this package as an alternative to Amp, but rather a very lightweight way of managing dynamic generated child processes. We have some use cases in which the functionality of this package (once it's done) is sufficient. We're aiming for less overhead (also meaning less functionality), resulting in better performance. The most important differences between this package and amphp/parallel:

• Better performance - based on very crude benchmarks, I'm going to do a lot more tests soon.
• A different, more simple API.
• Less functionality, actually just one thing.
• PHP 7.1+ (we're using pcntl_async_signals).
• A+ compliant Promises. (Though I'm not 100% sure whether Amp promises changed with v2?)

I plan on working on this more the next two weeks during the holidays, so we'll have a better idea of what we're going to do with this afterwards.

[kelunik]

We're actually going to move away from pcntl_fork and use symfony/process instead.

Good to know! How well does symfony/process support Windows? Signals won't work there. Not sure whether this is a concern for you.

Do you plan to have your own Promise interface or are you going to use ReactPHP's interface? For A+ you will need some kind of event loop, because then() callbacks must always be executed asynchronously. ReactPHP only implements A, not A+.

[brendt]

Ah that was one more thing I forgot to mention: we're not concerned with Windows support 😊.

I was actually thinking about using using Guzzle promises, and to unwrap them in the await call. I haven't implemented the details yet, but I think that should work without an event loop.

So it's clear that it won't be really A+ right now, but in case we will ever expand on this package, I'd like to use promises right away, so we could go an even more asynchronous way if needed.

[kelunik]

Have fun with Guzzle's promises. 😉 Unfortunately, they don't really interop with anything else, even if they claim that. The periodic timer they suggest just hogs the CPU. If you want interop with other promises, don't use Guzzle's.

[brendt]

Ok thanks for the tip! We're going to get this working first without promises and see from there :)

[brendt]

I've since blogged about use cases for this package: https://www.stitcher.io/blog/asynchronous-php

I'm going to close this issue for now.