Avoid incorrect usage of partially-initialized objects in reactors
benchmark
#360
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.
The
PingPong
andStreamingPingPong
sub-benchmarks use an inner class to work around the circular dependency between theping
andpong
reactors. However, because reactors execute asynchronously with respect to the main thread and because the communication between the two reactors is started before the inner class is fully initialized, thepong
reactor may actually observe an uninitialized reference (inner class instance variable) to theping
reactor (thepong
reactor's event handler may start executing before the constructor of the inner class finishes). This is most likely what is going on in #359.Because the reactor initialization mixes code executed synchronously with lambdas that capture environment but execute asynchronously (event handlers), the ordering of things is not immediately obvious. The commits in this PR separate the reactor setup code from the code that starts the communication and make sure that both happen on the main thread to keep them ordered. In the PingPong-style benchmarks, even though the reference to the inner class instance becomes part of the closure of the event handling lambdas, the communication is started only after the inner class instance is fully initialized, which apparently fixes #359.
Similar changes (to start the communication on the main thread) have been made to the
ThreadRing
andRoundAbout
sub-benchmarks for clarity (no bugs have been reported for those).