Hi,

On Fri, 3 Aug 2007, Arjan van de Ven wrote:

quoted text
> On Fri, 2007-08-03 at 21:19 +0200, Roman Zippel wrote:
> > Hi,
> > 
> > On Fri, 3 Aug 2007, Jonathan Corbet wrote:
> > 
> > > Most comments last time were favorable.  The one dissenter was Roman,
> > > who worries about the overhead of using hrtimers for this operation; my
> > > understanding is that he would rather see a really_msleep() function for
> > > those who actually want millisecond resolution.  I'm not sure how to
> > > characterize what the cost could be, but it can only be buried by the
> > > fact that every call sleeps for some number of milliseconds.  On my
> > > system, the several hundred total msleep() calls can't cause any real
> > > overhead, and almost all happen at initialization time.
> > 
> > The main point is still that these are two _different_ APIs for different 
> > usages, so I still prefer to add a hrsleep() instead.
> 
> 
> I would actually prefer it the other way around; call the
> not-so-accurate one "msleep_approx()" or somesuch, to make it explicit
> that the sleep is only approximate...

Actually the hrsleep() function would allow for submillisecond sleeps, 
which might be what some of the 450 users really want and they only use
msleep(1) because it's the next best thing.
A hrsleep() function is really what makes most sense from an API 
perspective.

bye, Roman
-
unsubscribe notice
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/