|
Boost : |
From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-16 16:17:05
"MagomedAbdurakhmanov" <maq_at_[hidden]> 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:
boost::mutex::scoped_lock lock(monitor);
boost:condtion cv;
bool test = false;
boost::xtime xt;
boost::xtime_get(&xt, boost::TIME_UTC);
while (!test && cv.timed_wait(lock, xt));
//Wait until test is true or timeout occurs
//This would be a lot harder to get right if a relative time were
used
> 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.
> And ever wrong that catch(...) under VC6 will catch OS exceptions.
On the other hand, letting exceptions escape from the thread function
is also bad. 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();
}
Mike
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk