There is a bit of unfinished business left over from the revision,
namely AI-122. Instead of approving this interpretations with the
others that were applied in the revision, we decided that the
proposed resolution was wrong and left it open. It is the one
about timers for high resolution clocks requiring privilege because
of the potential for denial of service.
The last time it was discussed, I believe the consensus was that:
1. The denial of service issue does not occur on timer creation, but
when the timer is set. Specifically, it relates to setting small
repeat intervals.
2. The issue applies to all real time clocks, including CLOCK_REALTIME.
(It does not apply to CPU time clocks.)
Since that discussion, it has also occurred to me that for extremely
high resolution clocks there may be intervals that even a privileged
process should not be able to set. An error for this is probably
already allowed as an extension, but it would be worth standardising
the error number to be used. I propose the use of ENOTSUP, to
distinguish this case from a completely invalid timer value (EINVAL).
This is similar to how pthread_setschedprio() distinguishes between
unsupported and invalid priority values.
I have made an attempt at producing a set of changes. One problem
that I encountered was how applications can determine the minimum
repeat interval they can use. Possibly we should add a sysconf()
variable for this, but I haven't gone that far. At the moment there
is just a fixed "maximum minimum" for the limit(s). I have set it
at 10ms to correspond to the traditional HZ=100 timer resolution.
At page 2114 line 66936 section timer_getoverrun, after:
When a timer is armed with a non-zero it_interval, a periodic (or
repetitive) timer is specified.
add:
Implementations may impose a minimum limit on the time interval
specified in it_interval when timerid identifies a timer created
for a clock measuring real time. The limit is
implementation-defined and may be different for processes with
appropriate privileges and those without. In both cases the
limit, if any, shall be less than or equal to 10 milliseconds.
At page 2115 line 66975 section timer_getoverrun, add to the
timer_setting "may fail" error list:
[ENOTSUP] The timer was created for a clock measuring real time
and the it_interval member of value is greater than
zero and less than the implementation-defined limit
allowed for processes with appropriate privileges.
[EPERM] The timer was created for a clock measuring real time,
the calling process does not have appropriate
privileges, and the it_interval member of value is
greater than zero and less than the
implementation-defined limit allowed for processes
without appropriate privileges.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|