|
|
|
|
|
|
by thadeus_venture
5418 days ago
|
|
|
The most frustrating thing about Python is its community's complete denial about what a joke their concurrency situation is. Truth is python is not truly multi-threaded, and no, claiming that multi-process is the way to do parallel computation across the board is not a sane argument at all. It's religious zeal. My company is currently using it for web apps, and that's proving a pain (i.e. having to use proxy servers for database access to minimize connections across all the python process instances). Using python for anything more serious, like a message queuing system for example is even more prohibitive. People in charge should wake up and start taking serious steps about it. I guess PyPy is the biggest hope. Meanwhile in the JVM world.. |
|
|
Running Java threads on a single processor machines makes it not truly multi-threaded then? Python has multi-threading - due to GIL, only one of them execute at a time, which isn't very different from running multiple threads on a single processor machine. It facilitates concurrency, not parallelism.
> claiming that multi-process is the way to do parallel computation across the board is not a sane argument at all.
If you have n processing units, anything greater than n isn't parallel. Spawning 100 threads in a JVM doesn't give you 100 parallel workers(assuming JVM mapped those 100 JVM threads to 100 system threads).
Multi processes make perfect sense for parallel jobs. They do fine with nothing shared and message passing. They are problematic when the jobs need resource sharing.
> having to use proxy servers for database access to minimize connections across all the python process instances
That doesn't sound like pain. Some systems intentionally have kept db connection pooling outside the application server. Application server talks to the manager and manager delegates to the database.
> Using python for anything more serious, like a message queuing system for example is even more prohibitive.
Celery works great. Thank you.
For custom needs, there is gearman, then there is zeromq...and they are not written in Python, and I don't care, and that works for me.
> Meanwhile in the JVM world..
Then why not stick to the JVM world rather than crib and whine in Python world.