[ayush--s]

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?

[btown]

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.

[sillysaurusx]

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.