Sascha Seewald wrote:
What about adding a function boost::sleep_until() that takes a point in time and change boost::sleep() to take a duration?
I believe the choice was done deliberately, and is more generic. Altough you might not see much use for it, it will allow creating predictable behavior. In the case where you have more complicated timeout scheme only having relative sleep could be a problem. Lets take an example: You have to maintain a task that is started every 10 seconds. Now if you are doing this as: while(true) { ... do something ... relative_sleep(10); } you can see easily that you will accumulate an error from each run of the loop. boost::xtime xt; boost::xtime_get(xt); xt.sec += 10; while(true) { ... do something ... boost::thread::sleep(xt); xt.sec += 10; } you can see now that this works smoothly (of course ... do something ... will be assumed to last < 10 sec) You can always easily write a little relative sleep if you need along the lines: void sleep(int sec) { boost::xtime xt; boost::xtime_get(xt); xt.sec += sec; boost::thread::sleep(xt); } Please don't forget: the threading library supply you with the essential primitives. You might always need to create other convenience functions if needed. You cannot get the behaviour from the example when only a relative sleep is available. Does this make sense to you? Roland