You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You've included unit or integration tests for your change, where applicable.
You've included inline docs for your change, where applicable.
There's an open issue for the PR that you are making. If you'd like to propose a change, please open an issue to discuss the change or find an existing issue.
This adds optional CancellationToken parameters to all IndexSearcher.Search and SearchAfter methods, which is a breaking change to the API.
If an executor is provided in the constructor for multithreaded search, then the provided CancellationToken is passed to the Task.Wait(CancellationToken) method. If an executor is not provided, then it will call ThrowIfCancellationRequested() in the synchronous case at the evaluation of each leaf reader context.
This will not help cancellation for i.e. single-leaf reader contexts that might take a while to complete (that would require a much larger and messier change to add CancellationToken support to Scorer and ICollector, and benchmarking to ensure we don't hurt performance by doing so), but should at least help with many scenarios that require cancellation.
I wanted to publish this draft PR for feedback; please let me know if you like this direction or have concerns.
After taking a step back from this and considering that we are working on support for CancellationTokens, I wonder if we should consider removing LimitedConcurrencyLevelTaskScheduler.Shutdown() and always use CancellationToken instead?
If we do keep the LimitedConcurrencyLevelTaskScheduler.Shutdown() method, there are some things to consider:
Should we make LimitedConcurrencyLevelTaskScheduler public? The BCL doesn't have one and it is provided in the docs for TaskScheduler. But there is no ShutDown() on that implementation.
There are some tests where Shutdown() was called in Lucene that would likely perform better if we use it, since those lines were often commented out in Lucene.NET. However, using CancellationToken could be an alternative way to handle those cases.
The upside of using Shutdown() is that it aligns more closely to Lucene.
The upside of using CancellationToken is that it is more fine-grained and can potentially shut down a process quicker, since it will be able to intervene inside of the running task instead of prior to queuing the task.
Allowing a user-defined TaskScheduler still seems like a good idea, but since Microsoft didn't allow them to be cancelled, it seems like we should follow the CancellationToken approach instead of trying to shoehorn a way to cancel a TaskScheduler. Using the same CancellationToken to make LimitedConcurrencyLevelTaskScheduler stop queuing new work is also something that might be worth considering.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Adds basic cancellation support to IndexSearcher.
Fixes #922
Description
This adds optional CancellationToken parameters to all
IndexSearcher.SearchandSearchAftermethods, which is a breaking change to the API.If an executor is provided in the constructor for multithreaded search, then the provided CancellationToken is passed to the
Task.Wait(CancellationToken)method. If an executor is not provided, then it will callThrowIfCancellationRequested()in the synchronous case at the evaluation of each leaf reader context.This will not help cancellation for i.e. single-leaf reader contexts that might take a while to complete (that would require a much larger and messier change to add CancellationToken support to Scorer and ICollector, and benchmarking to ensure we don't hurt performance by doing so), but should at least help with many scenarios that require cancellation.
I wanted to publish this draft PR for feedback; please let me know if you like this direction or have concerns.