[Iftop-users] [PATCH] Reverse order of pthread_cond_signal()/pthread_mutex_unlock()

[Bill Nickless]

Valgrand was not happy with the order in which pthread_cond_signal()
and pthread_mutex_unlock() were being called.  Also see
https://docs.oracle.com/cd/E19455-01/806-5257/6je9h032r/index.html
which states "Call pthread_cond_signal() under the protection of the
same mutex used with the condition variable being signaled. Otherwise,
the condition variable could be signaled between the test of the
associated condition and blocking in pthread_cond_wait(), which can
cause an infinite wait."

Patch also available at:
https://github.com/wknickless/iftop/commit/4c2fc858dc90b497819f0580fa4723a23276be9a

Signed-off-by: Bill Nickless <bill at nonick.org>
---
 resolver.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/resolver.c b/resolver.c
index 6c4c21d..70394c2 100644
--- a/resolver.c
+++ b/resolver.c
@@ -508,12 +508,13 @@ void resolve(int af, void* addr, char* result,
int buflen) {
                 added = 1;
             }
         }
-        pthread_mutex_unlock(&resolver_queue_mutex);

         if(added == 1) {
             pthread_cond_signal(&resolver_queue_cond);
         }

+        pthread_mutex_unlock(&resolver_queue_mutex);
+
         if(result != NULL && buflen > 1) {
             strncpy(result, hostname, buflen - 1);
             result[buflen - 1] = '\0';
--
2.25.1