History log of /seL4-refos-master/libs/libmuslc/src/signal/sigtimedwait.c
Revision Date Author Comments
# ccc7b4c3 26-Mar-2013 Rich Felker <dalias@aerifal.cx>

remove __SYSCALL_SSLEN arch macro in favor of using public _NSIG

the issue at hand is that many syscalls require as an argument the
kernel-ABI size of sigset_t, intended to allow the kernel to switch to
a larger sigset_t in the future. previously, each arch was defining
this size in syscall_arch.h, which was redundant with the definition
of _NSIG in bits/signal.h. as it's used in some not-quite-portable
application code as well, _NSIG is much more likely to be recognized
and understood immediately by someone reading the code, and it's also
shorter and less cluttered.

note that _NSIG is actually 65/129, not 64/128, but the division takes
care of throwing away the off-by-one part.


# 400c5e5c 06-Sep-2012 Rich Felker <dalias@aerifal.cx>

use restrict everywhere it's required by c99 and/or posix 2008

to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.


# 2f437040 09-Aug-2012 Rich Felker <dalias@aerifal.cx>

fix (hopefully) all hard-coded 8's for kernel sigset_t size

some minor changes to how hard-coded sets for thread-related purposes
are handled were also needed, since the old object sizes were not
necessarily sufficient. things have gotten a bit ugly in this area,
and i think a cleanup is in order at some point, but for now the goal
is just to get the code working on all supported archs including mips,
which was badly broken by linux rejecting syscalls with the wrong
sigset_t size.


# feee9890 17-Apr-2011 Rich Felker <dalias@aerifal.cx>

overhaul pthread cancellation

this patch improves the correctness, simplicity, and size of
cancellation-related code. modulo any small errors, it should now be
completely conformant, safe, and resource-leak free.

the notion of entering and exiting cancellation-point context has been
completely eliminated and replaced with alternative syscall assembly
code for cancellable syscalls. the assembly is responsible for setting
up execution context information (stack pointer and address of the
syscall instruction) which the cancellation signal handler can use to
determine whether the interrupted code was in a cancellable state.

these changes eliminate race conditions in the previous generation of
cancellation handling code (whereby a cancellation request received
just prior to the syscall would not be processed, leaving the syscall
to block, potentially indefinitely), and remedy an issue where
non-cancellable syscalls made from signal handlers became cancellable
if the signal handler interrupted a cancellation point.

x86_64 asm is untested and may need a second try to get it right.


# c2cd25bf 06-Apr-2011 Rich Felker <dalias@aerifal.cx>

consistency: change all remaining syscalls to use SYS_ rather than __NR_ prefix


# b470030f 24-Mar-2011 Rich Felker <dalias@aerifal.cx>

overhaul cancellation to fix resource leaks and dangerous behavior with signals

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...


# 685e40bb 19-Mar-2011 Rich Felker <dalias@aerifal.cx>

syscall overhaul part two - unify public and internal syscall interface

with this patch, the syscallN() functions are no longer needed; a
variadic syscall() macro allows syscalls with anywhere from 0 to 6
arguments to be made with a single macro name. also, manually casting
each non-integer argument with (long) is no longer necessary; the
casts are hidden in the macros.

some source files which depended on being able to define the old macro
SYSCALL_RETURNS_ERRNO have been modified to directly use __syscall()
instead of syscall(). references to SYSCALL_SIGSET_SIZE and SYSCALL_LL
have also been changed.

x86_64 has not been tested, and may need a follow-up commit to fix any
minor bugs/oversights.


# 5b9429ad 10-Mar-2011 Rich Felker <dalias@aerifal.cx>

make sigtimedwait a cancellation point


# 0a949ebd 10-Mar-2011 Rich Felker <dalias@aerifal.cx>

don't fail with EINTR in sigtimedwait

POSIX allows either behavior, but sigwait is not allowed to fail with
EINTR, so the retry loop would have to be in one or the other anyway.


# 0b44a031 11-Feb-2011 Rich Felker <dalias@aerifal.cx>

initial check-in, version 0.5.0