Re: [PATCH glibc-2.44] Fix __pthread_timedblock for hurd

Sergey Bugaev, le sam. 22 août 2026 12:01:25 +0300, a ecrit:
> pthread_cond_timedwait and pthread_cond_clockwait both take absolute time.
> 
> But they are allowed to return spuriously,

Well, generally yes, but most often no, and people really do assume that
quite a lot...

I have tested this on Linux:

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/time.h>
#include <pthread.h>

void handle(int sig) {
	printf("handle\n");
}

int main(void) {
	pthread_cond_t cond;
	pthread_condattr_t condattr;
	pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
	struct timespec abstime;

	signal(SIGALRM, handle);
	alarm(2);

	pthread_condattr_init(&condattr);
	pthread_condattr_setclock(&condattr, CLOCK_MONOTONIC);
	pthread_cond_init(&cond, &condattr);

	pthread_mutex_lock(&mutex);
	clock_gettime(CLOCK_MONOTONIC, &abstime);
	abstime.tv_sec += 5;
	printf("waiting\n");
	pthread_cond_timedwait(&cond, &mutex, &abstime);
	printf("waited\n");
	pthread_mutex_unlock(&mutex);
	return 0;
}

pthread_cond_timedwait does *not* return spuriously, it keeps waiting
until the 5s are elapsed.

So I'd really rather *not* introduce such spurious wake-up, because they
will really be a surprise to various programs.

Again, what is actually supposed to wake the condition in the issue at
stake?

Samuel