Iterating through listeners GHashTable requires listeners_mutex lock

[mattc1170]

We are using gstinterpipe in a large video media server product that can have 100s of gstinterpipesrc and gstinterpipesink elements. Our application has seen crashes when gstinterpipesrc elements are being removed at the same time that gstinterpipesink elements are either being added or removed. When a gstinterpipesink element is added or removed, a call to gst_inter_pipe_node_add() or gst_inter_pipe_node_remove() is made wherein g_hash_table_foreach() will iterate through the listeners hash table to notify the listeners that a node has been added. This iteration can happen while a listener is being removed from the hash table by another thread.

The g_hash_table_foreach() calls need to be protected. Initial testing of a locking mechanism revealed that using the existing GMutex listeners_mutex would cause deadlock because the same thread would need to lock the mutex twice under certain circumstances. Changing the listeners_mutex to a GRecMutex and protecting the g_hash_table_foreach() calls with this new mutex seems to have fixed the crashes in our application.

I will submit a patch or PR with our suggested code changes.

[michaelgruner]

Thanks! looking forward to the PR

[mattc1170]

Pull Request submitted: https://github.com/RidgeRun/gst-interpipe/pull/117