Re: Re: Refactoring our IO multiplexing layer

On Fri, Jun 20, 2014 at 6:29 PM, Daniel Lowrey <rdlowrey@gmail.com> wrote: > On 17 June 2014 12:05, Julien Pauli <jpauli@php.net> wrote: > >> Second question will be : do we use, and then link against libevent >> (or any other lib that could fit the need) > > Another particularly strong argument for using a libuv backend is that it > packages fully non-blocking and cross-OS filesystem IO capabilities. You > simply cannot perform non-blocking filesystem IO without delegating the > work to threads and subsequently notifying the main thread asynchronously > upon completion. Here's a useful intro on this topic: That's where things start to turn dark. The library's threading system needs to be made compatible with our thread layer. And our thread layer is not the best designed one... Joe.W would have lots of things to bring to the subject, waiting for his thoughts :-) I was not particulary thinking about filesystem non-blocking IOs, but network's , when first writing this email. Althought I knew some people would bring interesting subjects such as this one. > > http://www.remlab.net/op/nonblock.shtml > > In theory libuv would completely obviate the need for most (all?) of PHP's > existing filesystem code. If we're talking nbio backend alternatives, libuv > vs. libevent shouldn't really be a question. > > P.S. As Generators are now a thing in PHP (thanks, Nikita!), the addition > of built-in non-blocking facilities would mean the language has all the > necessary building blocks to utilize powerful language level concurrency > structures. To avoid userland segmentation and massive library duplication > I think a separate RFC to consider basic structures like CommonJS Promises > or Scala-style Future primitives (my personal preference) would also be > expedient. That would be a nice idea to propose :-) Julien