News for hackers. Stuff that matters.
Re:Show HN: Bringing multithreading to Python's async event ... by quotemstr on Saturday September 28, 2024 @04:21PM (#41682712)
At that point, why bother with asyncio? What we really want is something like Java virtual threads, something that doesn't have a code color.
Re:Show HN: Bringing multithreading to Python's async event ... by btown on Saturday September 28, 2024 @05:06PM (#41683007)
gevent is exactly this! http://www.gevent.org/

My startup has been using it in production for years. It excels at I/O bound workflows where you have highly concurrent real-time usage of slow/unpredictable partner APIs. You just write normal (non-async) Python code and the patched system internals create yields to the event loop whenever you’d be waiting for I/O, giving you essentially unlimited concurrency (as long as all pending requests and their context fit in RAM).

https://github.com/gfmio/asyncio-gevent does exist to let you use asyncio code in a gevent context, but it’s far less battle-tested and we’ve avoided using it so far.

Re:Show HN: Bringing multithreading to Python's async event ... by sidmitra on Thursday October 03, 2024 @08:05AM (#41729893)
I love gevent, but i never was 100% sure that nothing is secretly breaking or some weird thread safety issue. In a large SaaS app all sorts of 3rd party libs do weird background threading stuff or someone randomly starts doing threading.Local and shared global context. After hitting some weird hanging redis-py client issues, i turned gevent off and it went away. Never really got around to spend time to debug the issue(especially since it happened on prod and hard to replicate on stage/local).

Does your app have a lot of dependencies that do background threads? Like Launchdarkly(feature flags), redis, spyne(rpc) and on and on.

Re:Show HN: Bringing multithreading to Python's async event ... by whalesalad on Thursday October 03, 2024 @10:09AM (#41730972)
We also heavily use gevent but this is indeed the greatest frustration. Random and difficult to diagnose issues in external libraries like sockets being closed prematurely or timing out.
Re:Show HN: Bringing multithreading to Python's async event ... by drowsspa on Saturday September 28, 2024 @05:30PM (#41683134)
Not for those of us stuck in Java 8... Is it stable already?
Re:Show HN: Bringing multithreading to Python's async event ... by quotemstr on Saturday September 28, 2024 @11:17PM (#41684598)
I hear that some Amish sects permit the use of technology that's older and proven not to be too worldly, like washing machines, chainsaws, and Java 11. Have you considered converting?
Re:Show HN: Bringing multithreading to Python's async event ... by drowsspa on Monday September 30, 2024 @03:41PM (#41701208)
Yeah... Unfortunately golden handcuffs are binding me to the financial sector and, specifically, to Hadoop
Re:Show HN: Bringing multithreading to Python's async event ... by fnord123 on Thursday October 03, 2024 @04:28AM (#41728503)
Hadoop >=3.3 supports Java11.
Re:Show HN: Bringing multithreading to Python's async event ... by svieira on Thursday October 03, 2024 @11:29AM (#41731681)
Virtual threads only became stable in Java 21, unfortunately (https://openjdk.org/jeps/444). If the issue is "I'm bound to Java 8" proposing running a research build of Java 11 in production is going to fly as well as a lead balloon on the moon.
Re:Show HN: Bringing multithreading to Python's async event ... by drowsspa on Friday October 04, 2024 @05:37AM (#41739580)
Even so, it's pretty new, isn't it? I don't quite trust the claim it's completely transparent to applications and libraries...
Re:Show HN: Bringing multithreading to Python's async event ... by nbsande on Sunday September 29, 2024 @02:23AM (#41685314)
Hmmm. That would indeed be better. Seems like an interesting experiment to try and implement virtual threads for python!