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
{{ message }}
This repository has been archived by the owner on Aug 3, 2020. It is now read-only.
I've noticed the bug particularly in the tunnel receive, but it may as well be present elsewhere too.
Essentially, if while blocking for an outside event on a wait, both the event arrives as well as the connection is torn down (i.e. last message of a tunnel, after which it is closed), then Java will happily exit the wait successfully, but the threads interrupted-flag remains set, so the next sleep/wait/join will immediately cause an exception.
One solution would be to always clear the interrupted flag after a notify is received, ensuring racy conditions are handled. Of course, this is if teh JVM always prioritizes notifies. If it sometimes throws the exception, then additional code is needed at that point too to check for notification and succeed if such cases.
The text was updated successfully, but these errors were encountered:
I've noticed the bug particularly in the tunnel receive, but it may as well be present elsewhere too.
Essentially, if while blocking for an outside event on a wait, both the event arrives as well as the connection is torn down (i.e. last message of a tunnel, after which it is closed), then Java will happily exit the wait successfully, but the threads interrupted-flag remains set, so the next sleep/wait/join will immediately cause an exception.
One solution would be to always clear the interrupted flag after a notify is received, ensuring racy conditions are handled. Of course, this is if teh JVM always prioritizes notifies. If it sometimes throws the exception, then additional code is needed at that point too to check for notification and succeed if such cases.
The text was updated successfully, but these errors were encountered: