"Michael Glassford" <glassfordm@hotmail.com> writes:
"Darryl Green" <darryl.green@unitab.com.au> wrote in message news:loom.20040419T065628-962@post.gmane.org...
Michael Glassford <glassfordm <at> hotmail.com> writes:
"MagomedAbdurakhmanov" <maq <at> mail.ru> wrote in message news:200404160031.i3G0VZO1023813 <at> milliways.osl.iu.edu...
Hello. I have some troubles with boost::thread, and think they
are
important:
1. condition::timed_wait dangerous to use, because waiting delay
specified as time
when we are will stop waiting. So this is very surprising when system time is changed! I guess that waiting for specified delay is much more safe than waiting until some time arrive.
I'll have to think about this. It would break a lot of code to change this now, and there are some good reasons for specifying an absolute time instead of a relative time. For example, if you use the recommended loop to wait on the condition variable, using an absolute time is at the very least a lot more convenient.
The real problem isn't relative vs absolute (It is clear that absolute is the only choice for accurate timing) but what the clock is. It would be better to expend effort on supporting alternate clocks, in particular something similar to posix CLOCK_MONOTONIC. A monotonic clock would address the original issue (system time changing).
The links in Alexander Terekhov's post also mention this. Do you have any suggestions how to implement something along these lines?
On Windows, you could use GetTickCount to do the timing, with GetSystemTimeAsFileTime and SystemTimeToFileTime to get the limits --- e.g. const SYSTEMTIME suppliedEndTime=...; FILETIME endTime={0}; SystemTimeToFileTime(&suppliedEndTime,&endTime); FILETIME startTime={0}; GetSystemTimeAsFileTime(&startTime); DWORD const initialTick=GetTickCount(); ULONGLONG const diff=reinterpret_cast<ULARGE_INTEGER const&)(endTime).QuadPart- reinterpret_cast<ULARGE_INTEGER const&)(startTime).QuadPart; ULONGLONG const elapsedTicks=diff/10000; ASSERT(elapsedTicks<=ULONG_MAX); while((GetTickCount()-initialTick)<elapsedTicks) { doStuff(); }
2. The secound trouble is that the thread function has
catch(...) at
the root and
when unhandled exception in thread thrown, it's just silently eated and thread stopped. But the process stay alive, and now nothing about it.
It does know something (that the thread has terminated) about it if it joins the thread. It won't need to know anything about it if the thread doesn't throw unhandled exceptions. I'm not at all sure what Mag actually wants the library to do in this case?
And ever wrong that catch(...) under VC6 will catch OS exceptions.
So don't use VC6...
Unfortunately, though I'm open to correction, isn't this also true under later versions of VC? At least as a compiler option?
I think this is always true under VC7.1, too. What you can do is call set_unexpected_handler in the thread startup code, but I am not sure that this is any better than catch(...) As for what one should do with an unhandled exception in a thread... don't know. Terminate sounds good, but you could do with a means of forcing other threads to unwind. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd.