A question on whether this library is blocking

[Vectorial1024]

Hi there! This looks like a good concept.

I notice this library is using Symfony Process to execute async PHP code. Will this block until the async code is complete? Or maybe there is a way for us to check the progress of the async code, to see whether it is complete or not?

[terremoth]

Hi! Good question. It is using symfony process when on Windows. Maybe I can create something to check if the proccess was terminated or is running.

The code as it is now does not blocks, which is good and it is the purpose of this lib. So, it is completely async.

Pull requests are also welcome if you wanna try to implement.

[Vectorial1024]

I am asking this because some time ago I made a package for Laravel which is basically the same as this one:

https://github.com/Vectorial1024/laravel-process-async

Sadly, it has almost zero usage.

Maybe the usage would be higher if it was available as a general PHP package. I am interested to contribute to this package to see if my hypothesis is true, but at least you would need to know what the objectives/targets are.

[terremoth]

Nice, I saw your solution.

Maybe the usage would be higher if it was available as a general PHP package

Indeed. I agree.

you would need to know what the objectives/targets are

Targets: people who, for some reason, don't want, or cannot install or use swoole or parallel.

Both solutions you have to either use docker, compile yourself by hand, or have a hacky way to use it on Windows. Too much "work" for a thing that, IMO should be simple, when you just could use composer and add a solution like this.

[Vectorial1024]

I suddenly remember something about async in PHP that should probably also be discussed. It's basically my reflection on the purposes of making these kind of libraries, and after that I decided to stop touching my Laravel async library because I can't answer my own question.

---

There are two flavors of async:

• Concurrent async: async/await, e.g. NodeJS, Python asyncio, etc.
• Parallel async: spawning threads, going multi-processing, e.g. Java/C#, etc.

Swoole belongs to concurrent async. Then, there are hints that PHP 8.5 will have some sort of coroutine async built into the runtime. I think they say the coroutine API is experimental to more conveniently adjust the API to suit actual usage/practice, but if people want native concurrent async, they will most probably go for Swoole or just wait for the 8.5+ coroutine async.

What is left is parallel async. But then, we have the following situation:

If we are starting with something new, and are simply looking at available options to brainstorm the architecture, we might just go with heavy-duty languages like Java/C#, or perhaps even Rust/Go.

If we are working with web PHP, then nothing is stopping us from abusing FrankenPHP workers by sending web requests to self to simulate parallel async programming.

If we are not working with web PHP, this means we are working with CLI PHP, but then we already have pthreads a long time ago.

Then, what would be the purpose of a PHP async library that spawns processes?

[terremoth]

You are completely right in all the appointments you made.

If we are not working with web PHP, this means we are working with CLI PHP, but then we already have pthreads a long time ago.

pthreads seems dead long time. People are using Parallel (pecl extension) in its place. Pecl is also broken, deprecated and buggied on Windows. PHP Foundation guys are writing a new extension manager to ship with php (we expect that) in the future: pie

Then, what would be the purpose of a PHP async library that spawns processes?

I updated the README yesterday and gave some use-case examples. But yeah, it is even more useful on CLI applications than web ones. As I said: if it is possible to use FrankenPHP, Parallel or Swoole, there is no need to use this lib. I see this lib useful where you are using limited scenarios: you cannot, or don't want, or could be overkill using those solutions. Users that hire cheap PHP host companies to host their apps can see benefit in this library.

I just like to build things and test if they can do the job. I don't hope this lib became famous or replace other good solutions. When I created this lib I didn't have any expectations, but there are people already using which I became impressed when I knew.

I see this lib as a smart and tricky way to literally make something true async and running in parallel without download any extension, compile anything, change any config etc. And it worked.

[Vectorial1024]

I suddenly remember something about PHP, perhaps it will be a valid and convincing use case.

---

For example, when using pure PHP + Apache to handle web requests, normally the response is simply returned at the end of the script, and Apache will then send the response through the network. Here, it is not possible to do something after sending the response because the response is literally the last step of web processing.

There are workarounds e.g. using ob_end_flush() and ob_flush(), but imo that's just dangerous because afaik forgetting to do one of these two function calls will ruin the feature:

• forgetting ob_end_flush() will mean the supposed background task also counts towards web request timing, and the web browser will keep saying "loading page"
• forgetting ob_flush() will mean the intended contents never arrive

This workaround also means the background tasks are counted towards the Apache web requests limit, which may not be what we want. This will be a problem if we are receiving many web requests, and then some of them will have long do-after-response tasks.

It's also enabling spaghetti code by allowing the main logic to run on to the background task.

Here, it is much better when, at the end of the PHP script, we explicitly spawn a separate process to handle the do-after-response stuff, and then return the response as normal. This eliminates possibility of coding mistake and can improve code quality.

---

Admittedly I have no idea how many % of PHP users are not using frameworks, but this should be a very good use case.

[terremoth]

Yes, well thought out. This indeed could be an use case.