Reintroduce the ext-eio adapter #112
Conversation
WyriHaximus
force-pushed
the
0.2.x-reointroduce-eio-adapter
branch
5 times, most recently
from
7c14347 to
b325284
Compare
WyriHaximus
force-pushed
the
0.2.x-reointroduce-eio-adapter
branch
2 times, most recently
from
75f631c to
6e91496
Compare
This ties in directly with reactphp/filesystem#112 where if both ext-eio and ext-uv are present ext-uv interferes with ext-eio. By putting it lower in the factory construction method it will favor ext-eio over ext-uv for filesystem I/O is there is also a another event loop extension present.
There was a problem hiding this comment.
@WyriHaximus Great progress! I've added some questions below, but like the direction overall!
WyriHaximus
force-pushed
the
0.2.x-reointroduce-eio-adapter
branch
4 times, most recently
from
bea9816 to
f683982
Compare
WyriHaximus
force-pushed
the
0.2.x-reointroduce-eio-adapter
branch
4 times, most recently
from
913b2fa to
d7085d0
Compare
|
@clue updated the PR with findings regarding ext-eio and ext-uv, managed to resolve the issues, details in review thread |
|
Does the new adapter handle when eio_open returns false (or any other call, but eio_open appears to be the most common)?, it's undocumented but if you look into the PECL library you can see the error path that RETURN_FALSE instead of -1 See #43 was the reason we had to move to the child process for file operations |
As in it returns false, and doesn't call the handler you give it. Or it calls with handler with a false?
Will have a thorough look again at #43, but during development, I haven't run into those issues for 0.2. 0.2 is aimed a keeping things a lot simpler and avoiding making the same mistakes I made in 0.1. |
WyriHaximus
force-pushed
the
0.2.x-reointroduce-eio-adapter
branch
from
c6187f8 to
f380a64
Compare
During the initial rewrite this adapter was removed to make the rewrite easier. Since that is now in adding the ext-eio adapter will provide several high performance adapters.
WyriHaximus
force-pushed
the
0.2.x-reointroduce-eio-adapter
branch
from
f380a64 to
e469054
Compare
|
@WyriHaximus I've noticed the new eio related classes don't currently have 100% code coverage, is this something you plan to look into? Otherwise no objects to go ahead with this from my end 👍 |
|
@clue yes, in the next PR I'll address several code coverage issues across the board by covering more situations such as partial reads. |
|
Personally, I'd like to see better code coverage for this new adapter to make sure we're not introducing any regressions before moving forward with this. For instance, the @WyriHaximus Let's merge this as is? |
|
@clue Works for me, that is exactly what I'll be addressing in the follow up PR |
During the initial rewrite this adapter was removed to make the rewrite easier. Since that is now in adding the ext-eio adapter will provide several high performance adapters.