| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
as with clock_getres, the time64 syscall for this is not necessary or
useful, this time since scheduling timeslices are not on the order 68
years. if there's a 32-bit syscall, use it and expand the result into
timespec; otherwise there is only one syscall and it does the right
thing to store to timespec directly.
on 64-bit archs, there is no change to the code after preprocessing.
|
| | |
|
| |
|
|
|
| |
This brings the call to an actually usable speed.
Quick unscientific benchmark: 14ns : 102ns :: vDSO : syscall
|
| |
|
|
|
| |
This is a GNU extension, but a fairly minor one, for a system call that
otherwise has no libc wrapper.
|
| |
|
|
|
| |
these functions are expected to return an error code rather than
setting errno and returning -1.
|
| |
|
|
|
|
|
| |
the sched_getaffinity syscall only fills a cpu set up to the set size
used/supported by the kernel. the rest is left untouched and userspace
is responsible for zero-filling it based on the return value of the
syscall.
|
| |
|
|
|
| |
this is no longer used for anything, and reportedly clashed with a
builtin on certain compilers.
|
| | |
|
| |
|
|
|
|
|
| |
this first commit just includes the CPU_* and sched_* interfaces, not
the pthread_* interfaces, which may be added later. simple
sanity-check testing has been done for the basic interfaces, but most
of the macros have not yet been tested.
|
| |
|
|
|
|
|
|
|
|
| |
linux's sched_* syscalls actually implement the TPS (thread
scheduling) functionality, not the PS (process scheduling)
functionality which the sched_* functions are supposed to have.
omitting support for the PS option (and having the sched_* interfaces
fail with ENOSYS rather than omitting them, since some broken software
assumes they exist) seems to be the only conforming way to do this on
linux.
|
| | |
|
|
|
these actually work, but for now they prohibit actually setting
priority levels and report min/max priority as 0.
|
