Safe print() and multithreading

print() is a recursive method that prints the node and its children. Current implementation was implemented to be called sequentially. In some cases, it is required to print the problem after and/or before solving which is done in a different thread, so the sequential assumption is not met.

Several checks for nullptr should be added to avoid segfaults (equivalent to the discussion we had about visualization).

(content moved to #365 )Also, there is some relevant information that could be printed as well:

• Address of state blocks (it's the way we can identify them, useful for debugging)
• If is_removing_
• For StateBlocks and Factors, if they are in the solver or not (that could be indirectly checked via notification list in problem).

Most of it is implemented in the branch gauss and I would move it to core via MR.

EDIT:

I was experiencing several problems still with the nullptr checks when calling print() from the solver thread. Also, it is non-sense that having a shared_ptr any object is destroyed. The nullptr checks only have sense for the weak_ptrs.

I guess the problem is not in the validity of the pointers but the lists. For example in CaptureBase::print() there is this line: for (auto f : getFeatureList()). I don't know what happens when simultaneously to this loop, this capture is removed (so its features are removed, this list is changing while iterating on it).

I don't know which is the best solution:

1. Avoid calling print() (or check()) from a different thread than the main one.
2. Copy the lists before iterating (no need of nullptr checks, the shared pointers stored in the list avoid their destruction).
3. Add a mutex and block it before modifying or reading anything.
4. EDIT: Change implementation of getXXXList() returning via copy may be the best solution?

This should be faced globally, visualization in a different thread will be the same...

EDIT 2:

I think that the best solution will be to change all getXXXList() functions in WOLF to return via copy to avoid this error anywhere. The cost of copying a list (or a map in the case of Trajectory) of pointers is very cheap.