Sujet : Re: Apache + mod_php performance
De : ldo (at) *nospam* nz.invalid (Lawrence D'Oliveiro)
Groupes : comp.os.vmsDate : 01. Oct 2024, 02:36:12
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vdfjmb$2ep6c$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
User-Agent : Pan/0.160 (Toresk; )
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.
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?
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.