eventually we may have a working "generic" implementation for archs that don't need anything special. in any case, the goal of having stubs like this is to allow early testing of new ports before all the details needed for threads have been filled in. more functions like this will follow.
on spurious wakeups/returns from __timedwait, pthread_join would "succeed" and unmap the thread's stack while it was still running. at best this would lead to SIGSEGV when the thread resumed execution, but in the worst case, the thread would later resume executing on top of another new thread's stack mapped at the same address. spent about 4 hours tracking this bug down, chasing rare difficult-to-reproduce stack corruption in a stress test program. still no idea *what* caused the spurious wakeups; i suspect it's a kernel bug.
this seeme to be the bug that prevented enabling of private futex support. i'm going to hold off on switching to private futexes until after the next release, and until i get a chance to audit all wait/wake calls to make sure they're using the correct private argument, but with this change it should be safe to enable private futex support.
this is not strictly required by the standard, but without it, there is a race condition where cancellation arriving just before async cancellation is enabled might not be acted upon. it is impossible for a conforming application to work around this race condition since calling pthread_testcancel after setting async cancellation mode is not allowed (pthread_testcancel is not specified to be async-cancel-safe). thus the implementation should be responsible for eliminating the race, from a quality-of-implementation standpoint.
no sense bloating apps with a function call for an equality comparison...
this is a "nonstandard" function that was "rejected" by POSIX, but nonetheless had its behavior documented in the POSIX rationale for fork. it's present on solaris and possibly some other systems, and duplicates the whole calling process, not just a single thread. glibc does not have this function. it should not be used in programs intending to be portable, but may be useful for testing, checkpointing, etc. and it's an interesting (and quite small) example of the usefulness of the __synccall framework originally written to work around deficiencies in linux's setuid syscall.
fix up clone signature to match the actual behavior. the new __syncall_wait function allows a __synccall callback to wait for other threads to continue without returning, so that it can resume action after the caller finishes. this interface could be made significantly more general/powerful with minimal effort, but i'll wait to do that until it's actually useful for something.