[Nut-upsdev] patch: Replace many usleep and some sleep calls with nanosleep
Frédéric Bohé
fredericbohe at eaton.com
Mon Nov 14 10:50:38 UTC 2011
On Sun, 2011-11-13 at 20:51 -0500, Charles Lepple wrote:
> On Nov 13, 2011, at 3:32 PM, Regid Ichira wrote:
>
> > --- On Sat, 11/12/11, Arnaud Quette <aquette.dev at gmail.com> wrote:
> >
> >>>>> - usleep(250000);
> >>
> >>>>> + struct timespec delay = {0, 250e6}; nanosleep(&delay, NULL);
> >>
> >>>> Would it be better to define a local version of usleep in terms of
> >>>> nanosleep? I suspect the library version already does that, but if the
> >>>> library version is going away, a local version is much more concise and
> >>>> readable than calling nanosleep directly. If there are concerns about
> >>>> linking, the local version could be, e.g, u_sleep, since all the calls
> >>>> are getting touched anyway.
> >>
> >>> Using AC_REPLACE_FUNCS(... usleep ...) in configure.in and providing a
> >>> common/usleep.c->usleep() replacement implementation, in case the
> >>> system doesn't provide it, is a better way to go. At least for now.
> >>> That way, we avoid regression, while supporting systems that do not
> >>> provide usleep.
> >>
> >> What would be more worthwhile (IMHO) is to modify the code to make use
> >> of the remaining time returned by nanosleep. Otherwise, I am not sure
> >> I see the benefit of this change.
> >>
> >
> > Does that summarize to:
> >
> > 1. Have a valid C code for:
> >
> > int
> > substitution_usleep(delay, remaining_time)
>
> My point was that if we are going to change everything, we should *use* the remaining time. But given that the delays are very short to begin with, and given that the drivers tend not to rely on the precision or accuracy of usleep(), I wonder why we would bother replacing all of these calls to begin with?
>
> Before we delve into discussions of implementation, I still think it is useful to find out what is going on in the Win32 libraries. If the underlying code sleeps with millisecond precision, using nanosleep() is a step in the wrong direction, IMHO.
What I understand from MSDN docs is that "sleep" functions (Sleep,
WaitFor*) API only allows milliseconds. But by default the actual
granularity is even bigger than a millisecond. You can set this
granularity to a minimum (via timeBeginPeriod function) but this has an
impact on the whole system so it has to be used carefully.
--
Team Open Source Eaton - http://powerquality.eaton.com
--------------------------------------------------------------------------
More information about the Nut-upsdev
mailing list