[Nut-upsdev] patch: Replace many usleep and some sleep calls with nanosleep

[Arnaud Quette]

Hey,

just reviving this thread...

2011/10/4 Charles Lepple <clepple at gmail.com>

> On Mon, Oct 3, 2011 at 1:42 PM, Arnaud Quette <aquette.dev at gmail.com>
> wrote:
> > Hi Regid,
> >
> > 2011/10/3 Stuart D Gathman <stuart at bmsi.com>:
> >> On 10/03/2011 01:02 PM, Regid Ichira 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.
> >
> > sorry, but Stuart is right.
> > I should have replied to your other (well, this one) report on this.
> > 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.
>
> Out of curiosity, what systems support nanosleep but don't support 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.
>

good idea!
would you (Regid and Charles) please take over this task?

Related is the question of what should be done with the Windows
> branch, which defines usleep() in terms of Sleep(). If nothing else,
> we should defer this until the Windows branch is ready to merge.
>

@Fred: can you please check what is available on Windows (ie nanosleep or
equivalent), and tell us back?

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20111112/31817a95/attachment.html>