Closed amir-khoshbakht closed 1 year ago
Personally, I wouldn't use 0.1
in production as it isn't as stable and predictable as 0.2
, which I'm currently field testing in a project. You can require 0.2
as react/filesystem:^0.2@dev
in your project.
by the version "1" I mean 1.0. How is it that this is done completely in async in node.js but not possible in php?
by the version "1" I mean 1.0.
That's just a label we assign to a tag providing certain expectations.
How is it that this is done completely in async in node.js but not possible in php?
It is completely async in PHP, and the 0.2 of this package will increase the stability of this package a lot in doing so. Also keep in mind that there is no non-blocking filesystem I/O, the way node.js, this package, and others building non-blocking/async tooling is to use threads to perform these blocking calls in making them async for the user.
by the version "1" I mean 1.0.
That's just a label we assign to a tag providing certain expectations.
How is it that this is done completely in async in node.js but not possible in php?
It is completely async in PHP, and the 0.2 of this package will increase the stability of this package a lot in doing so. Also keep in mind that there is no non-blocking filesystem I/O, the way node.js, this package, and others building non-blocking/async tooling is to use threads to perform these blocking calls in making them async for the user.
My understanding is that : true non-blocking disk i/o is not possible in Windows, no matter what programming language you use. it is possible to have true non-blocking i/o in linux using Kqueue and Epoll but its not implemented in libuv.
good article about this topic.
after years, this package version is still is under 1. Is this package is reliable enough to use production environment ?