Possible extension to clock_nanosleep()
Adhemerval Zanella
adhemerval.zanella@linaro.org
Thu Aug 15 20:53:00 GMT 2019
On 15/08/2019 12:46, Eric Blake wrote:
> Today the Austin Group discussed
> http://austingroupbugs.net/view.php?id=1271, which is a proposal to add
> a way for clock_nanosleep() to return the current time in rmtp when
> using TIMER_ABSTIME, on the grounds that it might result in fewer
> syscalls in some forms of event loops.
>
> The conclusion of the POSIX folks is that the idea may have merit, but
> they are unwilling to standardize this (on the grounds of being pure
> invention) unless there is at least some hint of existing practice
> and/or some implementation preparing to add a feature along these lines,
> such that there is existing practice to refer to. Is glibc interested
> in adding an additional flag to clock_nanosleep() to be combined with
> TIMER_ABSTIME for getting at the current time at the completion of the
> function, to give the POSIX folks a reference implementation to act on?
>
> (I don't have contact information for the original reporter Scott
> Cheloha, or I would have included him in cc)
>
The extension seems reasonable, however I think the reference implementation
might be troublesome without proper kernel support because to return the
current time it might require an extra syscall. And depending of the
system load and scheduling the returned value might deviate by a large
margin from the actual real one.
This might work for vDSO implementations, where the latency is just for
function calls (but still susceptible to scheduling). But I am not sure how
it would play for the generic case.
So my questions are:
1. Is an implementation that might issue an additional syscall acceptable?
2. If it is not, is a vDSO-like fallback implementation suffice? Or should
the return time be acquired "atomically" regarding the sleep itself?
3. For a non vDSO-like interface we will need kernel support. It means we
will either need a new syscall or a extension, which means different
semantic depending of the kernel version. Would be acceptable as a
reference implementation?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190815/03ede8a5/attachment.sig>
More information about the Libc-alpha
mailing list