On Jul 27, 2013, at 11:37 PM, Ken Thomases <[email protected]> wrote:
> On Jul 27, 2013, at 8:29 AM, [email protected] wrote: > >> Ok so I went and looked at sys/time.h and friends and the man page for >> gettimeofday() >> And now understand how this struct works. >> It's literally the same as the NSDate method timeIntervalSince1970 >> The only difference is NSTimeInterval is representing the values if these >> struct fields as the respective sides of the decimal point. >> I grok this. >> If I want to fire my timer at the second, just supply a tp with tp.tv_usec >> as zero. > > Well, not quite. gettimeofday() fills in a struct timeval and a struct > timezone. dispatch_walltime() takes a struct timespec as its first > parameter. timeval+timezone vs. timespec. It's not entirely clear how you > would map from the first to the second. I suppose you could check the source > for dispatch_walltime() to see how it does it. I recommended continuing to > pass NULL for the timespec so that dispatch_walltime() would just do it for > you and instead pass a delta that adjusts this to (approximately) the next > whole second. > > But, yes, if you know the correct way to fill in the timespec for "now" and > you bump it up to the next whole second by incrementing its tv_sec field and > zeroing its tv_nsec, then that would also work. According to the man page for gettimeofday, time zone is not required if timeval is supplied. According to the docs, dispatch_walltime uses gettimeofday if NULL is passed for a timespec, and dispatch_walltime is based on gettimeofday. There is a macro in time.h to convert time spec to and from timeval clearly showing the two are identical except for the sub second unit used. #define TIMEVAL_TO_TIMESPEC(tv, ts) { \ (ts)->tv_sec = (tv)->tv_sec; \ (ts)->tv_nsec = (tv)->tv_usec * 1000; \ } #define TIMESPEC_TO_TIMEVAL(tv, ts) { \ (tv)->tv_sec = (ts)->tv_sec; \ (tv)->tv_usec = (ts)->tv_nsec / 1000; \ } > > >> Thanks Ken, you set me on the right track. > > You're welcome. Don't forget Rick Mann's original reply, which was along the > same lines but using NSTimer. (Which may still be a simpler way to go, since > you're reliant on the main thread being responsive anyway.) I haven't. Rick's clarity was there right off. But I'm avoiding NSTimer because I want to avoid being run looped in completely, though it's probably as practical as all this other mess :). > > Cheers, > Ken _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
