Hey, just reviving this thread...
2011/10/4 Charles Lepple <[email protected]> > On Mon, Oct 3, 2011 at 1:42 PM, Arnaud Quette <[email protected]> > wrote: > > Hi Regid, > > > > 2011/10/3 Stuart D Gathman <[email protected]>: > >> 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
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
