-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Throwing Away The Interrupt Flag by catching the InterruptedException #315
Comments
Thanks, I'll look at that, eventually, but is there anything that isn't working because of that for you application? |
We are running the framegrabber in its own thread at present. When we want to stop the thread we expect that anything that may be blocking will respond correctly to an InterruptedException by either rethrowing it or by "preserving state" and allowing the interrupt flag to propigate. This may have been causing our thread to deadlock in our application when trying to stop it because the interrupt flag was being eaten. We have been a slew of various problems with cameras and I'm trying to figure out all of the potential deadlock locations. Also, I would label this as a bug not an enhancement. |
I see, so calling |
Yes. I mean more ideal is passing the InterruptedException is better practice.
But if you are trying to not break your API then yes. This is fine. |
Sure, I rethrow the exception when it makes sense, but |
Let me know if the commits above are alright! Thanks |
The only one that I'm worried about is this one: 6875b0e#diff-a47e0edeb3dfdcb531fe9fa18e016ef6R210 By calling start the frame grabber is fulfilling a promise that when the method returns without an exception then the grabber will be working. Thoughts? |
Well, it probably doesn't work either if we exceed 100 counts either...
|
So both cases should throw an exception probably. But just make sure you preserve the interrupt flag like you have. |
Yeah, that sounds good. I've updated that in the latest commit above. |
That works. Cool!! Thanks for taking care of this. You guys are doing a great job with this library. |
There are at least 5 locations where this library simply catches an InterruptedException and does nothing with it.
https://github.com/bytedeco/javacv/search?utf8=%E2%9C%93&q=InterruptedException
http://www.ibm.com/developerworks/library/j-jtp05236/
How an InterruptedException should be handled in is detailed in the link above. In a nutshell, the InterruptedException should never be simply tossed away. You should always either propigate the exception or reset the threads interrupted flag.
The text was updated successfully, but these errors were encountered: