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