News for hackers. Stuff that matters.
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.