Motivation
A migration path off of eventlet for libraries/applications that exclusively rely on eventlet
Eventlet has different users with different use cases. This issue covers one specific subset of users: those who deliberately choose eventlet as their exclusive networking/event loop solution. A notable and relevant example is OpenStack.
My basic assumption is that the monkey-patching approach used by eventlet is fundamentally non-viable without massive engineering resources. For example, consider all the effort being put into patching RLock, when patching it actually introduces bugs (e.g. https://bugs.python.org/issue13697). A correct solution would involve maintaining a custom C RLock, and C Queue, and so on. And the more the Python stdlib changes, the harder eventlet maintenance becomes.
As such, I believe eventlet-only users are likely better off switching to event-driven frameworks like asyncio.
Access to asyncio libraries
Even if you disagree with the above, or you're a user who doesn't fit the above criteria, access to asyncio libraries in eventlet code is useful. Eventlet used to have Twisted support for this reason.
In general I don't think new features should be added to eventlet (see #835), but given that this aids with migration I think it's worth it.
I also believe it's easier to do this inside of eventlet rather than as an external project (see eventlet/aiohub#2).
The work involved
Prior art for gevent suggests this all should be possible. Each of these should be done as its own issue.
Questions
@temoto @tipabu what is your opinion on this approach of integrating asyncio and eventlet?
Motivation
A migration path off of eventlet for libraries/applications that exclusively rely on eventlet
Eventlet has different users with different use cases. This issue covers one specific subset of users: those who deliberately choose eventlet as their exclusive networking/event loop solution. A notable and relevant example is OpenStack.
My basic assumption is that the monkey-patching approach used by eventlet is fundamentally non-viable without massive engineering resources. For example, consider all the effort being put into patching RLock, when patching it actually introduces bugs (e.g. https://bugs.python.org/issue13697). A correct solution would involve maintaining a custom C RLock, and C Queue, and so on. And the more the Python stdlib changes, the harder eventlet maintenance becomes.
As such, I believe eventlet-only users are likely better off switching to event-driven frameworks like asyncio.
Access to asyncio libraries
Even if you disagree with the above, or you're a user who doesn't fit the above criteria, access to asyncio libraries in eventlet code is useful. Eventlet used to have Twisted support for this reason.
In general I don't think new features should be added to eventlet (see #835), but given that this aids with migration I think it's worth it.
I also believe it's easier to do this inside of eventlet rather than as an external project (see eventlet/aiohub#2).
The work involved
Prior art for gevent suggests this all should be possible. Each of these should be done as its own issue.
awaiting GreenThread in anasync defcontext. #887async deffunctions from inside greenlets #873asynciohub the default, after enough releases and real-world usage demonstrates correctnessQuestions
@temoto @tipabu what is your opinion on this approach of integrating asyncio and eventlet?