linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hubertus Franke <frankeh@watson.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: matthew@hairy.beasts.org, linux-kernel@vger.kernel.org,
	lse-tech@lists.sourceforge.net
Subject: Re: futex and timeouts
Date: Thu, 14 Mar 2002 10:19:48 -0500	[thread overview]
Message-ID: <20020314151846.EDCBF3FE07@smtp.linux.ibm.com> (raw)
In-Reply-To: <E16lMef-00022r-00@wagner.rustcorp.com.au>
In-Reply-To: <E16lMef-00022r-00@wagner.rustcorp.com.au>

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)

  reply	other threads:[~2002-03-14 15:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-13 18:26 futex and timeouts Hubertus Franke
2002-03-13 18:54 ` Ulrich Drepper
2002-03-14  4:15 ` Rusty Russell
2002-03-14 15:19   ` Hubertus Franke [this message]
2002-03-15  5:39     ` [PATCH] " Rusty Russell
2002-03-15  6:08       ` Joel Becker
2002-03-15  6:56         ` H. Peter Anvin
2002-03-15  8:49         ` Rusty Russell
2002-03-15 15:16         ` Hubertus Franke
2002-03-15 16:04           ` Joel Becker
2002-03-15 18:59             ` Hubertus Franke
2002-03-15 19:28               ` Joel Becker
2002-03-16  1:12                 ` [Lse-tech] " george anzinger
2002-03-18 21:35                   ` Hubertus Franke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020314151846.EDCBF3FE07@smtp.linux.ibm.com \
    --to=frankeh@watson.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=matthew@hairy.beasts.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).