Yarp: "yarpdev --list" deadlock if clock is enabled

[aerydna]

by starting yarpserver with the clock published (by gazebo in my trial) "yarpdev --list" freeze.

[aerydna]

I've found that the issue is caused by a call to DriversHelper::toString() method

1. that calls the scan() method
2. that calls yarp::os::Time::now() inside a Network::lock()

Now, as @barbalberto suggests me, the clock is basically lazy initialized and in our case has been created at this call of Time::now(). However, the initialization of the clock contains a Network::lock() causing the deadlock.

The constraint here is that the clock can't be initialized (can be used only if already created) inside a Network::lock().

By moving the lines containing Time::now() in YarpPluginSelector::scan(), out of Network::lock(), APPARENTLY everything works fine, although I doubt this represents a definitive solution.

[traversaro]

FYI, most of the history of development of NetworkClock support in YARP can be read in this issue : https://github.com/robotology/gazebo-yarp-plugins/issues/57 .

[randaz81]

This is pretty critical in many other applications and we need to fix it asap.
@barbalberto @drdanz What do you think?

[randaz81]

@aerydna said that if a yarp::os::time::now() is called in the main() function, before using a yarp port, the problem seems not to appear.
However, this issue has to be solved in yarp.

[drdanz]

What do you think about creating the clock in yarp::os::NetworkBase::initMinimum() (that is called by yarp::os::Network constructor, called by any YARP module)?

[barbalberto]

It'll probably work for this issue, but it feels more like a workaround to me...
I think the problem is in the Clock and derived classes about how they create and handle the clock, and the solution should be found there.

Do anyone knows why the call useNetworkClock does not creates the clock but uses instead the lazy initilization?
The only reason I may think of, is that maybe the yarpserver itself will hangs if run with YARP_CLOCK. If this is the case, maybe can yarpserver ignore this setting since it does not need to run on simulated time?
In my tests, many times just creating the clock when required fixes this type of issues while delaying the creation of the clock leads to un-expected behaviours because we don't actually know when the change of clock will take effect.

[barbalberto]

This has been fixed by commit 714bc50 on branch clockWIP (under testing)

[traversaro]

Fixed indevel by https://github.com/robotology/yarp/pull/1277, I guess? cc @barbalberto

[barbalberto]

yes, it is. yarpdev --list always uses system clock