fix deadlock

[vrabaud]

THAT WAS NOT FUN ! I SPENT A DAY ON THAT !
But it makes navigation work with tf2 so it's ok :)

Here is what's happening in some navigation tests I am switching to tf2.
In buffer_core.cpp, line 1298, a callback is being called in
testTransformableRequests after locking transformable_requests_mutex_
line 1256. This is actually defined through a message_filter. It is a
transformable that is being executed: it therefore locks
messages_mutex_ line 449 in message_filter.h. At the same time, a
message is added and the same mutex is locked line 308 in add but
line 321, a transformable is also added to the list in buffer_core
which calls a lock on transformable_requests_mutex_ line 1164 in
addTransformableRequest. Hence a deadlock.

[vrabaud]

please merge after review and I'll then finish up #76

[vrabaud]

and I might have found another one so please hold on. My fix might not be a full fix.

[vrabaud]

ok, the bug was in navigation, feel free to merge this one.

[mikeferguson]

A bug in navigation? no... that never happens. :)

[vrabaud]

actually, not a bug maybe. I opened up #80

[tfoote]

This does look to break the deadlock on the message_mutex_ however that was both protecting the message list as well as the target_frames_ list. With the change as proposed the iterator over the target_frames is unprotected.

I'm looking at extending the target_frames_strings_ mutex to cover the list as well, but I think it is actually the issue, since it's interated both in the transformable method as well as in the add.

[tfoote]

@vrabaud can you look at 10370e5 and possibly test. I think it keeps avoiding the deadlock, but keeps the target_frames_ iterators safe as a follow on to this patch.

[vrabaud]

ok, @tfoote I approve your fix and most of all, it works for navigation :)

[mikeferguson]

Yay!