Possible extension to clock_nanosleep()

Possible extension to clock_nanosleep()

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1104 bytes --]

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)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Possible extension to clock_nanosleep()

[Adhemerval Zanella]

[-- Attachment #1.1: Type: text/plain, Size: 2105 bytes --]



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? 
  


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]