Hi,
Over in [1], I thought for a moment that a new function
WaitLatchUs(..., timeout_us, ...) was going to be useful to fix that
bug report, at least in master, until I realised the required Linux
syscall is a little too new (for example RHEL 9 shipped May '22,
Debian 12 is expected to be declared "stable" in a few months). So
I'm kicking this proof-of-concept over into a new thread to talk about
in the next cycle, in case it turns out to be useful later.
There probably isn't too much call for very high resolution sleeping.
Most time-based sleeping is probably bad, but when it's legitimately
used to spread CPU or I/O out (instead of illegitimate use for
polling-based algorithms), it seems nice to be able to use all the
accuracy your hardware can provide, and yet it is still important to
be able to process other kinds of events, so WaitLatchUs() seems like
a better building block than pg_usleep().
One question is whether it'd be better to use nanoseconds instead,
since the relevant high-resolution primitives use those under the
covers (struct timespec). On the other hand, microseconds are a good
match for our TimestampTz which is the ultimate source of many of our
timeout decisions. I suppose we could also consider an interface with
an absolute timeout instead, and then stop thinking about the units so
much.
As mentioned in that other thread, the only systems that currently
seem to be able to sleep less than 1ms through these multiplexing APIs
are: Linux 5.11+ (epoll_pwait2()), FreeBSD (kevent()), macOS (ditto).
Everything else will round up to milliseconds at the kernel interface
(because poll(), epoll_wait() and WaitForMultipleObjects() take those)
or later inside the kernel due to kernel tick rounding. There might
be ways to do better on Windows with separate timer events, but I
don't know.
[1] https://www.postgresql.org/message-id/flat/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg%40mail.gmail.com
