Lack of native threading?

[lanforce]

Description

Why this is still not a part of the core?
Why can I just import threading in Python and use it right there without any hackinations?

PHP is like a white crow in the field of concurrency & computational capabilities, but yeah, we're focusing on some lazy objects to clean up Symfony... Sure the most wanted feature (not), lol.

[cmb69]

Why this is still not a part of the core?

The author had plans to suggest to integrate it into the Zend engine, but had been discouraged due to fibers having made it first. Maybe it is something we should consider. Perhaps @realFlowControl has some thoughts on this.

Anyhow, please stay civil here at least. Thanks!

[lanforce]

@cmb69 Wow, you're like a breath of fresh air here. I expected this issue to be closed almost immediately. 🤣

Will try to be civilized. Seeing all other languages have good support for concurrency with almost 0 configuration and then a lot of PHP folks tend to just "don't care" made me cry. And that's because I love PHP and wish it to be a better place in the parallelism/concurrency/computational field. It's already the king in the business area I would say, like this article highligths.

If PHP fixed those lackings, and maybe added a native performant production-ready HTTP server, this would neglect what other languages offer so we could stay in PHP for most of the use cases.

[NattyNarwhal]

I think historically, concurrency/parallelism for incoming requests tended to be orchestrated outside the PHP application (i.e. it came free with your web server starting PHP scripts), and most people weren't doing heavy MT computation in PHP. Fibres came in as Christoph mentioned, and take care a lot of remaining I/O situations you'd want threads for.

[determin1st]

im against threading. it is unsafe and the speed benefit vs process is not obvious. i dont really know what those NTS and TS mean for now, but ive already deleted fibers because they are not needed for asynchronicity (as well as generator)

added a native performant production-ready HTTP server

yes, as an extension without any additional branding, like a Curl extension is about Curl.

I think historically, concurrency/parallelism for incoming requests tended to be orchestrated outside the PHP application (i.e. it came free with your web server starting PHP scripts)

it is still the case. even the built-in web server php has (i deleted it). look at it as a closed resource, closed from the php file and the php code itself. php doesnt really have a grasp of those servers, they dont extend php. again, if given the interface like Curl's, php could abstract and wrap it into a nice asynchronous API

[cmb69]

[…], and most people weren't doing heavy MT computation in PHP.

What might be a chicken-and-egg problem. To my knowledge, there is only one publicly available extension for multi-threading, which may not be well-known, and for scientific computing there is Tensor which may be even less known, and I suppose is still rather suboptimal on Windows (due to the supporting libraries not being optimized there).

im against threading. it is unsafe […].

I think that mostly depends on the API. Low-level APIs (like these as the old pthreads) are hard to use correctly, but it seems to me that nowadays there are pretty easy to use (and such safe) APIs.

Actually, it's quite funny to see myself arguing in favor of multi-threading (I loved to switch to PHP for not having to deal with such issues), but nowadays some applications can't do without.

[lanforce]

im against threading. it is unsafe and the speed benefit vs process is not obvious. i dont really know what those NTS and TS mean for now, but ive already deleted fibers because they are not needed for asynchronicity (as well as generator)

Threads are a tool. Such statement could only sound from the person who never used threads in cases where they're an appropriate solution for the problem. Don't be a Shrek in your own swamp, we should have tools other languages have for decades. I've used threads from PHP's parallel extension and it's GOLD for my use cases. But somehow I need to find a maintained ZTS build and do a lot of unnecessary configuration in PHP to make it work smoothly, while in Python it works out-of-the-box with 0 dependencies and 0 configuration. Why PHP should somehow be worse than Python?

[bwoebi]

@lanforce you'll always need a thread safe build of PHP to do anything multithreading in PHP. How hard is it for you to use parallel? Like you're saying "a lot of unnecessary configuration", when it should be just downloading and extension=parallel.so

[pierrejoye]

On Wed, Sep 4, 2024, 11:19 PM determin1st ***@***.***> wrote: im against threading. it is unsafe and the speed benefit vs process is not obvious. i dont really know what those NTS and TS mean for now, but ive already deleted fibers because they are not needed for asynchronicity

TS enables locks and related ops when needed, where nts does nothing, while sharing the same macros/functions. as of thread vs not threaded, you may find frankenphp interesting, or refreshing.

…

[lanforce]

@lanforce you'll always need a thread-safe build of PHP to do anything multithreading in PHP. How hard is it for you to use parallel? Like you're saying "a lot of unnecessary configuration", when it should be just downloading and extension=parallel.so

Dude, have you ever used PHP threads in production? It sounds like you were toying with it and nothing more.
Imagine how it's for DevOps to maintain two separate versions of PHP (one NTS, second ZTS) in the cloud, putting different configurations for web requests and console modes to achieve the best performance and separation of process management. You don't do any downloading and extension=parallel.so for this in Python, and you don't maintain two language versions. I hope you at least understand why I don't use the ZTS build for serving the web requests.

P.S. Thanks to people like you, we broadly hear that PHP doesn't have threading and it's not a language to use if you want something more than the web.

[cmb69]

I don't see the need to discuss configuration options here. I rather see this as a feature request to have some userland MT capabilities always "built-in" (for ZTS builds, of course). In the past we've made ext/json and ext/hash mandatory, just so every user can rely on the extension being available (regardless of configuration, maybe even by shared hosting). And fibers have been adapted via https://wiki.php.net/rfc/fibers, which states:

Adding this capability directly in PHP core makes it widely available on any host providing PHP. Often users are not able to determine what extensions may be available in a particular hosting environment, are unsure of how to install extensions, or do not want to install 3rd-party extensions. With fibers in PHP core, any library author may use the feature without concerns for portability.

It sounds like you were toying with it and nothing more.

I don't think such assumptions are helpful.