On 12/01/20(Sun) 18:37, Philip Guenther wrote: > On Sun, Jan 12, 2020 at 4:44 AM Martin Pieuchot <m...@openbsd.org> wrote: > > > The consensus is now to switch syscall doing sleeps to use tsleep_nsec(9). > > Our direct goal is to stop expressing time as ticks, more might come > > later. > > > > The API futex(2) has a bug: it doesn't take a clockid_t and doesn't have a > way to take an absolute timeout, which means userspace has to do non-ideal > conversions to work around those limitations. While it might(?) make sense > to keep futex(2) the way it is to support ports that use that exact API**, > it feels like we should support a richer API to make libc/libpthread > happier...and perhaps not have the insane argument unuse/reuse/overloading > that futex(2) has (e.g., "pass uint32_t val2 as the fourth argument instead > of timeout"). > > Let's say a diff magically appeared splitting out three syscalls for the > three ops, with correct types and args and where timeouts were specified > with timespec+clockid_t+"is absolute" flag, can that be slotted into all > this without wailing and gnashing of teeth?
I'm not interested about making this turd shine myself. I won't oppose to such change. I'd just be pleased if we could finish the hz rampage. There are many uses of `hz' in base that would need some clever brain cell to be converted to other stuff. I would make me very happy if some of these algorithms, like pool cache, profiling, RX pressure, scheduling could receive some love :o)
