Austin Group Bug Tracker wrote:
The following issue has been CLOSED.
======================================================================
http://austingroupbugs.net/view.php?id=95
======================================================================
Reported By: msbrown
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 95
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
Status: Closed
Name: Mark Brown
Organization: IBM
User Reference:
Section: timer_getoverrun()
Page Number: 2114
Line Number: 66945
Final Accepted Text:
Resolution: Rejected
Fixed in Version:
======================================================================
Date Submitted: 2009-06-29 20:07 UTC
Last Modified: 2009-06-29 20:07 UTC
======================================================================
Summary: timer_getoverrun() and notification
Description:
_____________________________________________________________________________
COMMENT Enhancement Request
Number 25
mtk.lists:xxxxxxxxx Defect in XSH timer_getoverrun() (rdvk#
2)
{timer_getoverrun} Wed, 11 Feb 2009 00:32:04
GMT
_____________________________________________________________________________
The discussion of timer overruns in lines 66945 to 66956
is phrased entirely in terms of timer notification via
signals (SIGEV_SIGNAL). However, a timer overrun can also
occur for for notification via a thread (SIGEV_THREAD),
since there may be a delay between the timer expiration
and the invocation of the corresponding thread, and in
that time, further expirations may occur. Linux, at
least, supports timer_getoverrun() in the context of
timer notification via a thread, and perhaps other
systems also do. I suspect the standard should say
something about this, an that it may be an accident of
history that it doesn't.
Desired Action:
After line 66956, add text something like the following:
An implementation may also support the use of
timer_gettoverrun() for retrieving the overrun count
when timer expirations are notified via invocation of
a thread (SIGEV_THREAD). In this case, the overrun
count reflects the number of extra timer expirations
that have occurred between the first timer expiration
and the time that the notification thread was invoked.
======================================================================
----------------------------------------------------------------------
(0000136) msbrown (manager) - 2009-06-29 20:07
http://austingroupbugs.net/view.php?id=95#c136
----------------------------------------------------------------------
This aardvark request was rejected since time_getoverrun() is only defined
if the expiration causes signals to be generated.
timer_setoverrun() reports the number of signals not generated because
of overruns. When threads are used instead of signals, a thread will
be created for each event, independent of whether prior threads
handling these events have started or completed.
FWIW, the information given in the resolution of this bug does not, as
far as I can see, mirror reality on either Linux or Solaris (I tested
Solaris 8). On both of those systems, if, say, the process running the
timer is suspended for a period equal to multiple timer intervals, then,
when the process is resumed, the SIGEV_THREAD-invoked thread will report
a number greater than 0 when timer_getoverrun() is called, and as far as
I can tell, the number of threads invoked is consequently less than the
total number of timer expirations.
Cheers,
Michael
|