While this is not fixing a bug, intuition and literature suggest that
unlocking mutexes before signaling might help prevent the
freshly-woken-up thread from humping against the lock.

This also provides consistency with how things are approached in
parser.c:proc_parser() around line 1268.

OK?

Index: parser.c
===================================================================
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
diff -u -p -r1.158 parser.c
--- parser.c	23 Jun 2025 22:01:14 -0000	1.158
+++ parser.c	23 Jun 2025 22:09:27 -0000
@@ -1106,10 +1106,10 @@ parse_worker(void *arg)
 			if (pthread_mutex_lock(&globalmsgq_mtx) != 0)
 				errx(1, "pthread_mutex_lock");
 			ibufq_concat(globalmsgq, myq);
-			if (pthread_cond_signal(&globalmsgq_cond) != 0)
-				errx(1, "pthread_cond_signal");
 			if (pthread_mutex_unlock(&globalmsgq_mtx) != 0)
 				errx(1, "pthread_mutex_unlock");
+			if (pthread_cond_signal(&globalmsgq_cond) != 0)
+				errx(1, "pthread_cond_signal");
 		}
 	}