Ken Schumm
|
Re: pthread_cond_timedwait example in docs
|
Ken Schumm
03/24/2009 12:15 PM
post25120
|
Re: pthread_cond_timedwait example in docs
Yes, those would be a better way to go.
I just realized my example was also buggy since it only accounted for nsec periods of <= 2 billion and it would still
have the same problem if nsec was > 2 billion and < ffffffff.
> You could use the timespec2nsec and nsec2timespec functions from libc to
> go from nsecs to a timespec and back
>
> thanks
> shiv
> Tue Mar 24 12:10:43 EDT 2009
>
> --> According to Ken Schumm <--
> I spent some time chasing why a pthread_timedwait() call occasionally
> returned EINVAL in 3.4. It was my bug, but if the given example in the
> docs was a bit more detailed it would have saved some time so here's a
> suggestion.
>
> The given example timed wait call sets up a timer like this:
>
> struct timespec to;
>
> clock_gettime(CLOCK_REALTIME, &to);
> to.tv_sec += 5;
> .
> .
> pthread_cond_timedwait(...,&to)
>
> That's all well and good for periods measured in seconds.
>
> However, for periods measured in fractions of a second, when the tv_nsec
> field overflows 1000000000 (one billion) pthread_cond_timedwait()
> returns EINVAL. This is documented in the 3.4 release notes but not in
> the affected examples.
>
> It might be helpful if the given examples pointed out this issue.
> Something like this perhaps:
>
> #define BILLION 1000000000
> struct timespec to;
>
> clock_gettime(CLOCK_REALTIME,&to);
> to.tv_sec += 5;
> to.tv_nsec += 5000000 ;
> if(to.tv_nsec > BILLION) {
> to.tv_sec++ ;
> to.tv_nsec -= BILLION ;
> }
>
> Just a suggestion. The other functions affected by this EINVAL change in
> the release notes might benefit from this sort of clarification as well.
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post25116
>
>
> --
> ****
> Shiv Nagarajan,
> Kernel Developer, QNX Software Systems,
> Ottawa, Canada
> ****
|
|
|