this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit...
29 lines
523 B
C
29 lines
523 B
C
#include "pthread_impl.h"
|
|
|
|
static void relock(void *m)
|
|
{
|
|
pthread_mutex_lock(m);
|
|
}
|
|
|
|
int pthread_cond_timedwait(pthread_cond_t *c, pthread_mutex_t *m, const struct timespec *ts)
|
|
{
|
|
int r, e=0;
|
|
CANCELPT_BEGIN;
|
|
CANCELPT_END;
|
|
|
|
pthread_cleanup_push(relock, m);
|
|
c->_c_block = 1;
|
|
if ((r=pthread_mutex_unlock(m))) return r;
|
|
|
|
CANCELPT_BEGIN;
|
|
e = __timedwait(&c->_c_block, 1, c->_c_clock, ts, 0);
|
|
CANCELPT_END;
|
|
|
|
pthread_cleanup_pop(0);
|
|
if ((r=pthread_mutex_lock(m))) return r;
|
|
|
|
CANCELPT_BEGIN;
|
|
CANCELPT_END;
|
|
return e;
|
|
}
|