Conversation
📝 WalkthroughWalkthroughPlatform-aware RPC reader added in Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant ReceiveSocket
participant RPCProcess
participant Stdout
participant ServerSocket
Client->>ReceiveSocket: send data
ReceiveSocket->>RPCProcess: data available
alt Linux (_is_linux)
RPCProcess->>ReceiveSocket: uv.fs_sendfile -> stdout (fd 1)
loop repeat until EOF
ReceiveSocket-->>Stdout: file-send chunks
end
RPCProcess->>RPCProcess: detect len == 0 (EOF)
else Non-Linux (callback)
ReceiveSocket->>RPCProcess: read_start callback with data
RPCProcess->>Stdout: io.write(data)
alt data falsy
RPCProcess->>RPCProcess: detect EOF
end
end
RPCProcess->>ServerSocket: close
RPCProcess->>ReceiveSocket: close
RPCProcess->>RPCProcess: os.exit(0)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@lua/fzf-lua/rpc.lua`:
- Around line 37-49: The current tight loop calling uv.fs_sendfile synchronously
must be replaced with an async stream-based forwarder: stop calling
uv.fs_sendfile inside the while loop and instead call
receive_socket:read_start(callback) to receive chunks, then write those chunks
to server_socket (using server_socket:write or uv.write) inside the callback; on
nil/EOF from the read callback close receive_socket and server_socket and then
exit (or call uv.stop()/os.exit as appropriate), and ensure the libuv event loop
is driven (uv.run()) so the callbacks run; update the code paths around
uv.fs_sendfile, receive_socket, and server_socket to use this async
read_start/write pattern instead of the synchronous loop.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
|
Seems hang on non-linux... I abort the cij |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
lua/fzf-lua/rpc.lua (1)
48-60:⚠️ Potential issue | 🔴 CriticalAvoid the
fs_sendfiletight loop until its fd/error behavior is proven safe.If
uv.fs_sendfilereturnsnil, err,len == 0is false and this loop retries forever, hanging the RPC subprocess. Sincereceive_socketis an accepted libuv pipe/stream handle, the safe path is to keep the existingread_startforwarding unless this fd combination is explicitly verified.🐛 Proposed safe fallback
- if _is_linux then - while true do - local len = uv.fs_sendfile(1, receive_socket:fileno(), 0, 1024 * 1024) - local eof = len == 0 - if eof then finish() end - end - end - receive_socket:read_start(function(err, data) - assert(not err) - if not data then finish() end + assert(not err, err) + if not data then return finish() end io.write(data) end)To verify the dependency behavior, check the official docs/man page for the Neovim/libuv version in use:
#!/bin/bash set -euo pipefail # Verify libuv's documented fs_sendfile signature/behavior. curl -fsSL https://docs.libuv.org/en/v1.x/fs.html | grep -n -A8 -B4 'uv_fs_sendfile' # Verify Linux sendfile fd restrictions and error modes. curl -fsSL https://man7.org/linux/man-pages/man2/sendfile.2.html | grep -n -A35 -B8 'ERRORS'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lua/fzf-lua/rpc.lua` around lines 48 - 60, The tight loop using uv.fs_sendfile inside the _is_linux branch can hang if uv.fs_sendfile returns nil, err or an unexpected value; replace it with a safe attempt that checks the return values and falls back to the existing read-based forwarding: call uv.fs_sendfile once (or in a guarded loop) and if it returns an error (nil, err) or a non-positive length (len == 0) break out and invoke finish or switch to receive_socket:read_start forwarding, ensuring you reference _is_linux, uv.fs_sendfile, receive_socket:fileno(), read_start and finish so the code only uses fs_sendfile when its fd/error behavior is verified and otherwise relies on the existing read_start path.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@lua/fzf-lua/rpc.lua`:
- Around line 48-60: The tight loop using uv.fs_sendfile inside the _is_linux
branch can hang if uv.fs_sendfile returns nil, err or an unexpected value;
replace it with a safe attempt that checks the return values and falls back to
the existing read-based forwarding: call uv.fs_sendfile once (or in a guarded
loop) and if it returns an error (nil, err) or a non-positive length (len == 0)
break out and invoke finish or switch to receive_socket:read_start forwarding,
ensuring you reference _is_linux, uv.fs_sendfile, receive_socket:fileno(),
read_start and finish so the code only uses fs_sendfile when its fd/error
behavior is verified and otherwise relies on the existing read_start path.
|
local uv = vim.uv
require("fzf-lua").fzf_exec(function(cb)
coroutine.wrap(function()
local co = coroutine.running()
for i = 1, 20000000 do
cb(tostring(i), function()
coroutine.resume(co)
end)
coroutine.yield()
end
cb(nil)
end)()
end, {
multiprocess = false,
keymap = { fzf = { load = "abort" } },
winopts = {
on_create = function(e)
_G.start = uv.hrtime()
end,
on_close = function()
print((uv.hrtime() - _G.start) * 1e-9)
end,
},
}) |
6ms is still something :) |
Not sure will this be faster
Summary by CodeRabbit