guv
guv copied to clipboard
Implement PEP3156 event loop API
The PEP3156 event loop is the interface is Python's standard. The guv event loop should be restructured to implement this interface.
I'm by no means an expert when it comes to event loops - but how does libuv compare performance-wise to PEP3156's event loop? And should this matter?
@jaddison libuv is written in C and is most certainly much faster, cross-platform, and supports more interesting async features than the Python asyncio module's event loop implementation (which of course implements the PEP3156 interface). guv's core event loop consists of a wrapper around libuv via CFFI, so there's as little custom logic as possible already. However, the interface currently being used is built around libuv, and influenced by gevent and eventlet, with some of my own optimizations. It doesn't follow any standard interface.
It's not too difficult to restructure the event loop to implement the PEP3156 interface. Could probably be done in a weekend or so.
Is this a replacement or an optional loop the user could select? I could see people wanting to squeeze as much performance using libuv. On May 19, 2015 11:04 AM, "V G" [email protected] wrote:
@jaddison https://github.com/jaddison libuv is written in C and is most certainly much faster, cross-platform, and supports more interesting async features than the Python asyncio module's event loop implementation (which of course implements the PEP3156 interface). guv's core event loop consists of a wrapper around libuv via CFFI, so there's as little custom logic as possible already. However, the interface currently being used is built around libuv, and influenced by gevent and eventlet, with some of my own optimizations. It doesn't follow any standard interface.
It's not too difficult to restructure the event loop to implement the PEP3156 interface. Could probably be done in a weekend or so.
— Reply to this email directly or view it on GitHub https://github.com/veegee/guv/issues/24#issuecomment-103616072.
No no, there won't be an implementation change, just an interface change. It'll still use libuv and behave in exactly the same way. I'll just be changing the guv core event loop's function names a bit and do some code refactoring essentially to match PEP3156 loop interface.
Again, the actual loop currently in place behaves exactly the same. This change was suggested by @tarruda a few months ago.
This change will allow you to easily swap out guv's event loop with any other PEP3156-compatible loop if you like. It's merely to be compatible with the new Python event loop interface standard.
Ah! Sorry, my misunderstanding. Good stuff. On May 19, 2015 1:55 PM, "V G" [email protected] wrote:
No no, there won't be an implementation change, just an interface change. It'll still use libuv and behave in exactly the same way. I'll just be changing the guv core event loop's function names a bit and do some code refactoring essentially to match PEP3156 loop interface.
Again, the actual loop currently in place behaves exactly the same. This change was suggested by @tarruda https://github.com/tarruda a few months ago.
This change will allow you to easily swap out guv's event loop with any other PEP3156-compatible loop if you like. It's merely to be compatible with the new Python event loop interface standard.
— Reply to this email directly or view it on GitHub https://github.com/veegee/guv/issues/24#issuecomment-103665336.
Currently, pyuv_cffi (which is what guv is using) is fully compatible with @saghul's pyuv. If you do nothing more than change the imported library to pyuv, it should work exactly the same (other than very very slightly faster on CPython, and not at all on pypy). That being said, this is very good reference, if not almost copy/paste: https://github.com/saghul/aiouv