svn commit: r231906 - head/lib/libthr/thread
David Xu
listlog2011 at gmail.com
Sun Feb 19 11:00:24 UTC 2012
On 2012/2/19 18:52, Bruce Evans wrote:
> On Sun, 19 Feb 2012, David Xu wrote:
>
>> Log:
>> Check both seconds and nanoseconds are zero, only checking nanoseconds
>> is zero may trigger timeout too early. It seems a copy&paste bug.
>>
>> Modified:
>> head/lib/libthr/thread/thr_umtx.c
>>
>> Modified: head/lib/libthr/thread/thr_umtx.c
>> ==============================================================================
>>
>> --- head/lib/libthr/thread/thr_umtx.c Sun Feb 19 07:44:38 2012
>> (r231905)
>> +++ head/lib/libthr/thread/thr_umtx.c Sun Feb 19 08:17:14 2012
>> (r231906)
>> @@ -205,7 +205,7 @@ _thr_umtx_timedwait_uint(volatile u_int
>> if (abstime != NULL) {
>> clock_gettime(clockid, &ts);
>> TIMESPEC_SUB(&ts2, abstime, &ts);
>> - if (ts2.tv_sec < 0 || ts2.tv_nsec <= 0)
>> + if (ts2.tv_sec < 0 || (ts2.tv_sec == 0 && ts2.tv_nsec <= 0))
>> return (ETIMEDOUT);
>> tsp = &ts2;
>> } else {
>>
>
> Use timespeccmp()? It is even likely to be faster, since it can do the
> comparison in parallel, while the above has to wait for TIMESPEC_SUB()
> before doing the comparison, unless the compiler is very smart.
>
Yes
> However, I seem to have done too good a job of keeping kernel time* APIs
> out of userland, so timespeccmp() is only available in the kernel, and
> there are uglier but more correct unsafe macros like TIMESPEC_SUB()
> macros in userland, and various kernel APIs escaped anyway, starting
> with the NetBSD timeval ones, which escaped 10-15 years after timevals
> should have gone away because they were superseded by timespecs.
>
> Bruce
>
Yes, we noticed that all timespec macros are not available for userland,
even TIMESPEC_SUB was copied from kernel.
More information about the svn-src-all
mailing list