4 ms·
One of the reasons I love using gevent (https://www.gevent.org https://www.gevent.org) is that it's way of introducing concurrency that does preserve these atom
by btown 3y ago
One of the reasons I love using gevent (https://www.gevent.org https://www.gevent.org) is that it's way of introducing concurrency that does preserve these atomicity guarantees! Broadly speaking, the only time your code will be interrupted by something else in the same process is if some function call yields control back to the event loop - so if your block is entirely made up of code you control that doesn't do any I/O, you can be sure it will run atomically. And you get it for free without needing to rewrite synchronous code into asyncio.
This does make me wonder, though, if gevent will survive PEP 703's massive changes to internal Python assumptions. That said, gevent does work on pypy, so there's some history with it being flexible enough to port. Hopefully it won't be left behind, otherwise codebases using gevent will see this as a Python 2 -> 3 level apocalypse!
- BiteCode_dev 3y agoSame with asyncio, but you have explicit await to tell you where this happens. But this only solves network concurrency problems.
- slashdev 3y agoI’ve used gevent, but I don’t remember this behavior. How does it prevent the GIL from being released when running Python code?
- btown 3y agoAh - it's more that you wouldn't typically need to run multiple threads in the same process to handle concurrent requests. For instance, gunicorn used with gevent workers will typically fork processes to ensure all cores are used, but wouldn't require multiple threads per process - gevent would handle concurrency on a single OS thread within each process.
- slashdev 3y agoAh, got it. That makes sense. Very reasonable tradeoff for an application server, which is embarrassingly parallel and holds little state.