Re: Refactoring our IO multiplexing layer

On Tue, Jun 17, 2014 at 1:33 PM, Chris Wright <daverandom@php.net> wrote: > On 17 June 2014 12:05, Julien Pauli <jpauli@php.net> wrote: >> CCing internals >> >> On Tue, Jun 17, 2014 at 1:07 PM, Martin Pelikan >> <martin.pelikan@gmail.com> wrote: >>>> Still, there exist the excellent libevent >>>> http://libevent.org/ >>> >>> Speaking as only an observer to PHP development, I have been reinventing >>> this particular wheel in my project (SSH client to thousands of machines >>> to replace the painfully slow python's paramiko, as seen in my thesis at >>> http://qviz.storkhole.cz/). >>> >>> My ~3 months of experience: >>> >>> The questions you want to ask are: >>> - "what's wrong with libevent" >>> - "how would you do it differently" >>> - "why does PHP need it differently" >>> >>> I strongly suggest not creating yet another way of doing I/O multiplexing. >>> nginx looks pretty neat and shows just how much work is needed to get things >>> right on all platforms. PHP developers have better things to do than this. >>> >>> >>> http://trac.nginx.org/nginx/browser/nginx/src#event/modules >>> >>> If someone would say to me "learn and then read libevent" right away, my >>> backend would be finished now. Seriously. Go and have a look, it is >>> likely to save a lot of your time. >> >> Yes, libevent seems to be the API we need. >> Regading Nginx, I'm not sure we need file AIO, for PHP, network AIO >> could be enough to implement. Still, our FPM IO multiplexing layer is >> stable now. > > File AIO would still be nice to have though, it's common to pipe data > between a network fd and a file fd - when the file system blocks, that > can be a sizeable performance hit. Libuv seems nice as well, yes. Not sure about its licencing compatibility with us though. > > I may get shot for suggesting this, but libuv provides all the things > libevent provides, plus filesystem support (also, the built-in async > DNS resolution is a nice bonus). Why not use this part as well in our DNS resolutions, could be nice. > >> The problem of binding a lib is that you add one more dependency, you >> have to check for licence compatibility, and check for the dependency >> when building. Not talking about bugs in the lib impacting our >> codebase. This is a tradeoff. > > While this is very valid, in this particular case I believe it would > be worth it, due to the insane complexity of reinventing this > particular wheel. +1 ! > > I believe Daniel Lowrey and Joe Watkins were bouncing some ideas > around on exactly this subject off-list a few weeks ago, I'm not sure > whether they have anything tangible yet. So, waiting for them to jump into the topic :-) Julien