We aim to fix the opening of /.../img:o port. We realized that the port gets open only when the first image is received by the port /.../img:i during configuration.
What happens at the user level is that it is not clear that 2 subsequent connections are required from within the yarpmanager, plus the timing of the second connection is not deterministic, unfortunately.
The handling of /.../img:i is moved inside the visualization thread that is the only piece of code using it. As a consequence, we fix also possible race conditions that might be caused by reading images in the updateModule and consuming those images in the run (there is no mutex).
Tests
Tests are successful as @claudiofantacci did them extensively.
Problem
We aim to fix the opening of
/.../img:oport. We realized that the port gets open only when the first image is received by the port/.../img:iduring configuration.What happens at the user level is that it is not clear that 2 subsequent connections are required from within the yarpmanager, plus the timing of the second connection is not deterministic, unfortunately.
The handling of
/.../img:iis moved inside the visualization thread that is the only piece of code using it. As a consequence, we fix also possible race conditions that might be caused by reading images in the updateModule and consuming those images in the run (there is no mutex).Tests
Tests are successful as @claudiofantacci did them extensively.