Re: Apache + mod_php performance

On 9/30/2024 9:36 PM, Lawrence D'Oliveiro wrote:

On Mon, 30 Sep 2024 20:48:53 -0400, Arne Vajhøj wrote:

The world is moving from forking processes to starting threads.

 That was tried in the 1990s -- threads for everything, even multithreaded
GUIs. It was soon discovered that was not a great idea.

Practically all GUI's are multi-threaded.
At least a main thread and an event thread.

Java, perhaps, embraced threads more than anybody: it made such heavy use
of threads that it never even bothered to define a separate “lock” object
type: instead, locking calls are built into the behaviour of every object!
>
No other language copied that feature. Wonder why not?

There is no data in the object itself for it.
Java chose the syntax:
o.xxxx()
while .NET chose the syntax:
Monitor.Xxxx(o)
for this functionality.
Different syntax but same functionality.
I think the .NET syntax better explains what it does.
But it is just syntax.

As soon as Python are done getting rid of GIL then it will
join the thread party!

 We understand better what to use threads for these days. They are good for
CPU-intensive tasks that are parallelizable, not so much for anything
else. That CPU-intensive stuff is not something you would tend to do in
Python itself anyway: for high performance, you would delegate those tasks
to “extension modules” written in C or such compiled languages. The usual
flow within the extension code is
 * Grab data from Python objects into some efficient native format
* Free the GIL
* Perform CPU-intensive tasks
* Re-acquire the GIL
* return results in Python objects
 That third step takes full advantage of multithreading, without having to
worry about the strictures of the Python GIL.

Threading is also a very convenient programming model for IO.
Blocking IO API's has some limits on scalability (like 500 threads
per CPU core).
But then there are various flavors of non-blocking API's.
And then there are blocking looking but not blocking under
the hood API's.
Arne