"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?
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?
On the other hand, letting exceptions escape from the thread
function
is also bad. Bad = undefined or some other reason?
Bad = undefined, or at best implementation defined.
For what it's worth, the thread_function in the thread_dev branch (which I'm working on merging into the main branch as time allows) has this:
catch (...) { using namespace std; terminate(); }
How is this better?
I wasn't necessarily implying that it was better. My main reason for mentioning it (though I failed to say so) was to see what people thought about it.
It seems that it punishes other threads (preventing them from doing any sort of orderly termination) because this one has broken exception handling. Along the way, it forces an unwind, then terminate behavior, instead of the "normal" behaviour for an unhandled exception (admitedly what that is is implementatiation defined) which might have given a hint what was wrong. The old approach (which isn't perfect either, I'm just not seeing that this is clearly better) gives some chance of recovery by a joining thread. As we are apparently talking about obsolete compiler support above, one might as well note that calling terminate in an exception handler is documented to cause a deadlock on some versions of Kai C++.
Thanks for your comment.
Regards Darryl.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost