Re: Refactoring our IO multiplexing layer

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