Re: Refactoring our IO multiplexing layer

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. 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. Julien