4 ms·

Gevent is the best thing which ever happened within the async world of Python. It's just great to work with. Rock solid. I have high IO production software runn

by smetj 5y ago

Gevent is the best thing which ever happened within the async world of Python. It's just great to work with. Rock solid. I have high IO production software running for years with gevent as the workhorse, copes with high load, no maintenance, brilliant. Then came Asyncio, which I personally disliked for the simple reason it became so popular that everybody thinks it's necessary to write an asyncio version of their library/module. The result is it now tears everything in 2. Asyncio code and non-asyncio code ... Everything like Asyncio, Curio, Trio are impressive and interesting but their interfaces are way too involved for the intended result and it should never be like that. (Gevent suffered less from that). The only way forward is proper thread support without the GIL and therefor I applaud this effort.

ayush--s 5y ago
It's really easy to shoot yourself in the foot by using global mutable variables. How do you guard against those when using gevent in production?
- sillysaurusx 5y ago
  Global state isn't a problem for multithreaded code. State updates are the problem; it doesn't matter whether it's global or local. If you can solve the local case, you can solve the global case. Pick your technique; any ol' technique is just as good as any other.
- btown 5y ago
  It's actually quite doable in gevent, because you have a guarantee that only one thread will ever be touching those variables ever. You can have 5 or 50 lines of code and be guaranteed that they will operate atomically, read their writes, be immune to interruption, all that good stuff... as long as they don't do any I/O. Of course, the difference from a platform like Node.js or asyncio (where every async/await yield must be explicit all the way down) is that one of your libraries calling `logger.info(...)` might cause I/O, and then cause an implicit yield to the event loop, and break your atomicity without you knowing about it. But if you don't log, and you just work in memory, with code you own or have audited to not do I/O, the sky's the limit. And you almost always want this kind of well-tested, non-logging, high-performance abstraction layer around global mutable state access anyways.

by smetj 5y ago

ayush--s 5y ago

It's really easy to shoot yourself in the foot by using global mutable variables. How do you guard against those when using gevent in production?

sillysaurusx 5y ago
Global state isn't a problem for multithreaded code. State updates are the problem; it doesn't matter whether it's global or local. If you can solve the local case, you can solve the global case. Pick your technique; any ol' technique is just as good as any other.
btown 5y ago
It's actually quite doable in gevent, because you have a guarantee that only one thread will ever be touching those variables ever. You can have 5 or 50 lines of code and be guaranteed that they will operate atomically, read their writes, be immune to interruption, all that good stuff... as long as they don't do any I/O. Of course, the difference from a platform like Node.js or asyncio (where every async/await yield must be explicit all the way down) is that one of your libraries calling `logger.info(...)` might cause I/O, and then cause an implicit yield to the event loop, and break your atomicity without you knowing about it. But if you don't log, and you just work in memory, with code you own or have audited to not do I/O, the sky's the limit. And you almost always want this kind of well-tested, non-logging, high-performance abstraction layer around global mutable state access anyways.