oscpack / udpSocket: invert the "break_" semaphore #7963
Merged
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.
In the oscpack udpSocket listener thread there is a flag named
break_
which breaks the endless loop, resolving into the thread exiting "properly". because of the threading approach of ofxOscReceiver being changed fromdetach()
tojoin()
, a new race condition emerges: in theclose()
of the ofxOscSender theasynchronousBreak()
function is called, which sets the flag to true in order to break the listener, but there are cases where the listener thread has not spun up yet, but will be forced to by thejoin()
, and the first thing it does inRun()
is to resetbreak_
to false, this removing the flag and creating the hang (theRun()
will never return).this changes inverses the logic: the
break_
is initialized to false, and changed back to false at the end ofRun()
. this way if it's changed to true before the thread start, the thread immediately stops. resetting the flag to false makes the object reusable (even though the ofxOscReceiver pattern will re-create a new object when re-started())(note: the
volatile bool
is also upgraded tostd::atomic<bool>
)this solves the
INSTANTLY_OUT_OF_SCOPE
test case documented in #7949