On Wednesday 13 March 2002 11:15 pm, Rusty Russell wrote:
> In message <20020313182552.945523FE06@smtp.linux.ibm.com> you write:
> > Ulrich, it seems to me that absolute timeouts are the easiest to do.
> >
> > (a) expand by additional parameter (0) means no timeout desired
> > (b) differentiate the schedule call in futex_down..
> >
> > Question is whether the granularity of jiffies (10ms) is sufficiently
> > small for timeouts.....
>
> 1) You must not export jiffies to userspace.
>
> 2) They are not a time, they are a counter, and they do wrap.
>
> 3) This does not handle the settimeofday case: you need to check in
> userspace for that anyway.
>
> So, since you need to check if you're trying to sleep for longer than
> (say) 49 days, AND you need to check if you are after the given
> abstime in userspace anyway (settimeofday backwards), you might as
> well convert to relative in userspace.
>
> Sorry,
> Rusty.
3) I think one of us is misunderstanding (its probably me)
What I was proposing was a relative wall clock time, vs application virtual
time.
interface would be to always specify in futex how long to wait (relative) and
not until when to wait (absolute).
What I propose is not to export jiffies (ofcourse not), but either usecs or
msecs and whether one should state what the minimum wait time is.
Right now we know it can't be less then 10ms (x86) unless we busywait and
above that the granularity will be in 10ms increments.
So from the previous post of code example, one has to add the conversion from
timeout to timeout_jiffies.
Also we need to determine the best API for this. Somebody (Rusty ?) suggest to
pass a pointer to (struct timeval) vs a single counter. Only disadvantage is
an additional copy_from_user, but it gives much bigger timeouts.
I think its a good idea to add it.
-- -- Hubertus Franke (frankeh@watson.ibm.com) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:17 EST