Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why not support "Asyncio handler" #499

Closed
EchoShoot opened this issue Mar 25, 2018 · 1 comment
Closed

why not support "Asyncio handler" #499

EchoShoot opened this issue Mar 25, 2018 · 1 comment

Comments

@EchoShoot
Copy link

I sincere recommend kazoo to support asyncio handler,
your know twisted can be transform object from asyncio ,
in the future, may more and more Asynchronous framework can be transform object from asyncio!
i meaning that it will support a lot of frameworks if kazoo support asyncio!

-- your loyal fans

@tonyseek
Copy link
Contributor

tonyseek commented Dec 6, 2018

The current implementation of connection routine uses blocked-style handler.select. It works well with monkey patch based solutions but does not work with asyncio.

In my opinion, this is a price for that asyncio chooses to use explicit scheduling and introduces new backward-incompatible syntax. So many libraries are hard to adapt asyncio without breaking Python 2.x users. Even the standard DBAPI2 and WSGI libraries could not be adapted too until new PEP was published. Adapting native asyncio means maintaining a standalone branch for Python 3.x users only, just like what Gunicorn do.

For Kazoo, using the threading handler in Python 3.x and asyncio may be fine enough, since Python 3.x has resolved the performance problem of GIL when multi-threading is enabled. The background kernel thread to maintain ZooKeeper connection avoids starving caused session expired also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants