Enhance openDir
to Respect Buffer Size
#55817
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #55764
The current
openDir
implementation does not fully respect the buffer size. This PR introduces an initial solution based on suggestions from @Ethan-Arrowood. Feedback on the concept would be appreciated.PR Status
Proposed Solution
I am currently working on a
#handlerQueue
that stores areadNext
function.readNext
callshandler.read
, and if the return value is notnull
, it re-adds itself to the queue for continued processing.Note: This solution might be modified or scrapped, but the aim here is to get the conversation started. And just get the work done.
Current Challenges
handler.read
does not always populatethis.#bufferedEntries
—for instance, when a directory is empty. This creates issues with triggeringthis.processNextHandler
after every yield, as it may yield nothing.readSync