- 15 10月, 2011 6 次提交
-
-
由 Rich Felker 提交于
it's a keyword in c++ (wtf). i'm not sure this is the cleanest solution; it might be better to avoid ever defining __NEED_wchar_t on c++. but in any case, this works for now.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
this may be useful to posix_spawn..?
-
由 Rich Felker 提交于
musl's dynamic linker does not support unloading dsos, so there's nothing for this function to do. adding the symbol in case anything depends on its presence..
-
由 Rich Felker 提交于
mildly tested; may have bugs. the locking should be updated not to use spinlocks but that's outside the scope of this one module.
-
由 Rich Felker 提交于
-
- 10 10月, 2011 1 次提交
-
-
由 Rich Felker 提交于
the fcntl syscall can return a negative value when the command is F_GETOWN, and this is not an error code but an actual value. thus we must special-case it and avoid calling __syscall_ret to set errno. this fix is better than the glibc fix (using F_GETOWN_EX) which only works on newer kernels and is more complex.
-
- 09 10月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 05 10月, 2011 1 次提交
-
-
由 Rich Felker 提交于
no idea why these 4 are permuted and the rest are standard/generic
-
- 04 10月, 2011 1 次提交
-
-
由 Rich Felker 提交于
...and still be valid in #if directives.
-
- 03 10月, 2011 6 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
right now it's questionable whether this change is an improvement or not, but if we later want to support priority inheritance mutexes, it will be important to have the code paths unified like this to avoid major code duplication.
-
由 Rich Felker 提交于
this is valid for error-checking mutexes; otherwise it invokes UB and would be justified in crashing.
-
由 Rich Felker 提交于
this simplifies the code paths slightly, but perhaps what's nicer is that it makes recursive mutexes fully reentrant, i.e. locking and unlocking from a signal handler works even if the interrupted code was in the middle of locking or unlocking.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
- 01 10月, 2011 6 次提交
-
-
由 Rich Felker 提交于
a reader unlocking the lock need only wake one waiter (necessarily a writer, but a writer unlocking the lock must wake all waiters (necessarily readers). if it only wakes one, the remainder can remain blocked indefinitely, or at least until the first reader unlocks (in which case the whole lock becomes serialized and behaves as a mutex rather than a read lock).
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
mildly tested, seems to work
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
- 29 9月, 2011 7 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
passing null pointer for %s is UB but lots of broken programs do it anyway
-
由 Rich Felker 提交于
there is no need to send a wake when the lock count does not hit zero, but when it does, all waiters must be woken (since all with the same sign are eligible to obtain the lock).
-
由 Rich Felker 提交于
seeking back can be performed by the caller, but if the caller doesn't expect it, it will result in an infinite loop of failures.
-
由 Rich Felker 提交于
eliminate the sequence number field and instead use the counter as the futex because of the way the lock is held, sequence numbers are completely useless, and this frees up a field in the barrier structure to be used as a waiter count for the count futex, which lets us avoid some syscalls in the best case. as of now, self-synchronized destruction and unmapping should be fully safe. before any thread can return from the barrier, all threads in the barrier have obtained the vm lock, and each holds a shared lock on the barrier. the barrier memory is not inspected after the shared lock count reaches 0, nor after the vm lock is released.
-
由 Rich Felker 提交于
i think this works, but it can be simplified. (next step)
-
由 Rich Felker 提交于
the vm lock only waits for threads in the same process exiting. actually this fix is not enough, but it's a start...
-
- 28 9月, 2011 11 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
it was assuming the result of the condition it was supposed to be checking for, i.e. that the thread ptr had already been initialized by pthread_mutex_lock. use the slower call to be safe.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
we're not required to check this except for error-checking mutexes, but it doesn't hurt. the new test is actually simpler/lighter, and it also eliminates the need to later check that pthread_mutex_unlock succeeds.
-
由 Rich Felker 提交于
when used with error-checking mutexes, pthread_cond_wait is required to fail with EPERM if the mutex is not locked by the caller. previously we relied on pthread_mutex_unlock to generate the error, but this is not valid, since in the case of such invalid usage the internal state of the cond variable has already been potentially corrupted (due to access outside the control of the mutex). thus, we have to check first.
-
由 Rich Felker 提交于
i set the return value but then never used it... oops!
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
not sure if this is correct/ideal. it needs further attention.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-