fd waits for the whole traversal if the only matches arrive within max_buffer_time #868
Assignees
Labels
Comments
|
Thank you for reporting this! |
tavianator
added a commit
to tavianator/fd
that referenced
this issue
Nov 26, 2021
The new ReceiverBuffer struct allows us to factor out the receiver
implementation into a number of helper methods. The new implementation
uses rx.{recv,recv_timeout} instead of a for loop, which enables us to
switch to streaming mode at the right time without waiting for more
results.
Fixes sharkdp#868.
tavianator
added a commit
to tavianator/fd
that referenced
this issue
Nov 26, 2021
The new ReceiverBuffer struct allows us to factor out the receiver
implementation into a number of helper methods. The new implementation
uses rx.{recv,recv_timeout} instead of a for loop, which enables us to
switch to streaming mode at the right time without waiting for more
results.
Fixes sharkdp#868.
tavianator
added a commit
to tavianator/fd
that referenced
this issue
Nov 27, 2021
The new ReceiverBuffer struct allows us to factor out the receiver
implementation into a number of helper methods. The new implementation
uses rx.{recv,recv_timeout} instead of a for loop, which enables us to
switch to streaming mode at the right time without waiting for more
results.
Fixes sharkdp#868.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If all the matches are received very quickly, within
max_buffer_time, then they'll be added to the buffer without being printed. The first match to arrive after the time limit will kick it into streaming mode, but if we never get any more matches then that never happens and we'll wait for the whole search to complete before printing anything.I guess the fix is to use
rx.recv_timeout()instead offor worker_result in rxhere.The text was updated successfully, but these errors were encountered: