"Joachim Schmitz" <j...@schmitz-digital.de> writes:

>> I see no existing code calls setitimer() with non-NULL ovalue, and I
>> do not think we would add a new caller that would do so in any time
>> soon, so it may not be a bad idea to drop support of returning the
>> remaining timer altogether from this emulation layer (just like
>> giving anything other than ITIMER_REAL gives us ENOTSUP).  That
>> would sidestep the whole "we cannot answer how many milliseconds are
>> still remaining on the timer when using emulation based on alarm()".
> Should we leave tv_usec untouched then? That was we round up on
> the next (and subsequent?) round(s). Or just set to ENOTSUP in
> setitimer if ovalue is !NULL?

I was alluding to the latter.

>> > +  switch (which) {
>> > +          case ITIMER_REAL:
>> > +                  alarm(value->it_value.tv_sec +
>> > +                          (value->it_value.tv_usec > 0) ? 1 : 0);
>> Why is this capped to 1 second?  Is this because no existing code
>> uses the timer for anything other than 1 second or shorter?  If that
>> is the case, that needs at least some documenting (or a possibly
>> support for longer expiration, if it is not too cumbersome to add).
> As you mention alarm() has only seconds resolution. It is tv_sec
> plus 1 if there are tv_usecs > 0, it is rounding up, so we don't
> cancel the alarm() if tv_sec is 0 but tv_usec is not. Looks OK to
> me?

Can a caller use setitimer to be notified in 5 seconds?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to