You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by GitBox <gi...@apache.org> on 2021/02/16 14:20:05 UTC
[GitHub] [lucene-solr] donnerpeter opened a new pull request #2378: LUCENE-9779: Hunspell: add an API to interrupt long computations
donnerpeter opened a new pull request #2378:
URL: https://github.com/apache/lucene-solr/pull/2378
<!--
_(If you are a project committer then you may remove some/all of the following template.)_
Before creating a pull request, please file an issue in the ASF Jira system for Lucene or Solr:
* https://issues.apache.org/jira/projects/LUCENE
* https://issues.apache.org/jira/projects/SOLR
You will need to create an account in Jira in order to create an issue.
The title of the PR should reference the Jira issue number in the form:
* LUCENE-####: <short description of problem or changes>
* SOLR-####: <short description of problem or changes>
LUCENE and SOLR must be fully capitalized. A short description helps people scanning pull requests for items they can work on.
Properly referencing the issue in the title ensures that Jira is correctly updated with code review comments and commits. -->
# Description
For example, to ensure responsiveness, IntelliJ-based IDEs periodically call a special method which can throw a dedicated exception. This allows the currently executed computation to be interrupted and release all the locks it holds, allowing the UI thread to grab them as quickly as possible.
# Solution
Pass a `Runnable` to `Hunspell` constructor that may throw whatever exceptions the environment expects when needed
# Tests
`HunspellTest.testCheckCanceled`
# Checklist
Please review the following and check all that apply:
- [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability.
- [x] I have created a Jira issue and added the issue ID to my pull request title.
- [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the `master` branch.
- [x] I have run `./gradlew check`.
- [x] I have added tests for my changes.
- [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene-solr] dweiss merged pull request #2378: LUCENE-9779: Hunspell: add an API to interrupt long computations
Posted by GitBox <gi...@apache.org>.
dweiss merged pull request #2378:
URL: https://github.com/apache/lucene-solr/pull/2378
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on pull request #2378: LUCENE-9779: Hunspell: add an API to interrupt long computations
Posted by GitBox <gi...@apache.org>.
dweiss commented on pull request #2378:
URL: https://github.com/apache/lucene-solr/pull/2378#issuecomment-780350006
Control-flow by exception is something I'm not particularly fond of, to be honest... I'd rather see a predicate (and graceful return) or leverage of existing Java mechanisms (Thread.checkInterrupted) to implement this. I realise a generic Runnable throwing an unchecked exception works in this case too (and is convenient for catching up the stack) but would you consider just resorting to checking the thread's interrupted status? The IDE can catch interrupted exception or wrap and rethrow as needed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene-solr] donnerpeter commented on pull request #2378: LUCENE-9779: Hunspell: add an API to interrupt long computations
Posted by GitBox <gi...@apache.org>.
donnerpeter commented on pull request #2378:
URL: https://github.com/apache/lucene-solr/pull/2378#issuecomment-780373942
> Control-flow by exception is something I'm not particularly fond of, to be honest... I'd rather see a predicate (and graceful return) or leverage of existing Java mechanisms (Thread.checkInterrupted) to implement this. I realise a generic Runnable throwing an unchecked exception works in this case too (and is convenient for catching up the stack) but would you consider just resorting to checking the thread's interrupted status? The IDE can catch interrupted exception or wrap and rethrow as needed.
I've considered a `BooleanSupplier` and I couldn't decide which results to produce in `spell`/`suggest` during graceful return, and how to prevent callers from caching them (incorrectly). Exception solves both problems :)
There's no `Thread.checkInterrupted` in my JDK 11, did you mean something else? Anyway, `InterruptedException` is a checked one, and I'd prefer innocent clients not to care about that, so then one would have to decide which unchecked exception to use instead. Besides, the IDE that I have in mind has complicated relations with interrupted threads, which have a history of corrupting caches there. It's not unsolvable, but requires some care that not everybody has :(
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on pull request #2378: LUCENE-9779: Hunspell: add an API to interrupt long computations
Posted by GitBox <gi...@apache.org>.
dweiss commented on pull request #2378:
URL: https://github.com/apache/lucene-solr/pull/2378#issuecomment-780381762
Sorry - I wrote it off the top of my head. It should be Thread.currentThread().isInterrupted() which checks for the interrupted flag on the current thread. It doesn't throw anything, it merely checks the flag. How to return from an aborted computation is another question...
Interrupting things prematurely is always messy - I don't know if there's a clean way to do it, especially if you have sub-threads or I/O involved...
Ok, let's leave it your way then.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org