Anthony Williams wrote:
As the POSIX spec points out, there is a race condition implementing an absolute timeout on top of a relative-timeout-based API. If we want to support absolute timeouts (and we do)
But why does this imply forcing everybody to use absolute timeouts only in the boost interface? Sure, there are as many uses for relative timeouts as there are for absolute timeouts in an interface, yet only absolute timeouts have this race condition. IMHO it makes more sense to use relative timeouts internally and have users compute relative timeouts for their absolute timeouts if they need them. The benefit would be that the absolute time needs to be queried only once to compute a relative timeout in code that wishes to work with absolute timeouts, eliminating the race condition on Windows. POSIX "users" can get predictable behavior using CLOCK_MONOTONIC even with the boost code internally using relative timeouts. Making this change, the race condition goes away on one more platform using in the boost interface. It should also be considered that relative timeouts in the boost interface certainly eliminate a problem on a platform with a large market share relevant to many boost developers for better or worse ;-) As "xtime" is documented as "...temporary solution that will be replaced by a more robust time library once available in Boost." I cannot see a good argument to keep it given its real problems. Further, the relative timeouts also create a much neater interface compared to what is currently needed to get something as simple as a 10 millisecond timeout: xtime t; get_xtime(&t, TIME_UTC); t.nsec += 10000000; if(t.nsec >= 1000000000) { t.nsec %= 1000000000; t.sec++; } condition bar; bar.timed_wait(somelock, t); to condition bar; bar.timed_wait(somelock, 10000000); For the absolute time case, the date_time library would be a nice help (not that I have used it before, so not sure the code below would be legal or not). First, looking at the current code (assuming "myabsolutetime" is a ptime object): time_duration td(second_clock::universal_time() - myabsolutetime); xtime t; t.nsec = td.total_nanoseconds() % 1000000000; t.sec = td.total_nanoseconds() - t.nsec; condition bar; bar.timed_wait(somelock, t); to time_duration td(second_clock::universal_time() - myabsolutetime); condition bar; bar.timed_wait(somelock, td.total_nanoseconds()); A lot nicer, isn't it? - Especially I strongly assume most programs rarely need absolute timeouts just a few milliseconds or even nanoseconds apart and using the date_time library's potential overhead (assuming there is a significant overhead) will not be a major burden for those who need absolute timeouts. Of course, what this does not address is the issue of absolute timeouts that intentionally depend on absolute time being changed by the user ... but is this really so important to justify a fully absolute timeout-based interface? Thorsten