From: Job Snijders <job@openbsd.org>
Subject: Re: rpki-client: pthreads first unlock then signal
To: Ted Unangst <tedu@tedunangst.com>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, tech@openbsd.org
Date: Tue, 24 Jun 2025 08:00:44 +0000

On Tue, Jun 24, 2025 at 12:46:16AM -0400, Ted Unangst wrote:
> > Is there a reason to signal and then unlock? If that is the case,
> > shouldn't the calls around line 1268 parser.c:proc_parser() be be
> > reversed?
> 
> I think it's clearer to keep the mutex held around the signal, lest
> somebody start changing things and then the mutex disappears entirely.
> You need the mutex at least to decide when to signal.
> 
> It's correct either way.

In that case, 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	24 Jun 2025 08:00:07 -0000
@@ -1265,10 +1265,10 @@ proc_parser(int fd, int nthreads)
 				if (pthread_mutex_lock(&globalq_mtx) != 0)
 					errx(1, "pthread_mutex_lock");
 				TAILQ_CONCAT(&globalq, &myq, entries);
-				if (pthread_mutex_unlock(&globalq_mtx) != 0)
-					errx(1, "pthread_mutex_unlock");
 				if (pthread_cond_signal(&globalq_cond) != 0)
 					errx(1, "pthread_cond_signal");
+				if (pthread_mutex_unlock(&globalq_mtx) != 0)
+					errx(1, "pthread_mutex_unlock");
 			}
 		}
 	}