Hello Michael, Saturday, April 17, 2004, 1:17:05 AM, you wrote:
1. condition::timed_wait dangerous to use, because waiting delay MG> specified as time when we are will stop waiting. So this is very surprising when MG> system time is changed! I guess that waiting for specified delay is much more safe than MG> waiting until some time arrive.
MG> I'll have to think about this. It would break a lot of code to change MG> this now, and there are some good reasons for specifying an absolute MG> time instead of a relative time. For example, if you use the MG> recommended loop to wait on the condition variable, using an absolute MG> time is at the very least a lot more convenient: Ok. But we don't need to change the behavior by default. Much better to allow both methods to wait. So we can choose which method is better in our case. For example timed_wait can be overloaded (or provides another metod) for period argument. Something like this: boost::xtime_period xtp(1000); if (cv.timed_wait(xtp)) { // ... }
2. The secound trouble is that the thread function has catch(...) at MG> the root and when unhandled exception in thread thrown, it's just silently eated MG> and thread stopped. But the process stay alive, and now nothing about it. And ever wrong that catch(...) under VC6 will catch OS exceptions.
MG> On the other hand, letting exceptions escape from the thread function MG> is also bad. For what it's worth, the thread_function in the MG> thread_dev branch (which I'm working on merging into the main branch MG> as time allows) has this: MG> catch (...) MG> { MG> using namespace std; MG> terminate(); MG> } MG> Mike This is better than just silently catch them. But there is a advantage if we let to escape exceptions from thread. I'll speak about win32: when application throws exception somewhere and terminates, the OS can inform the code instruction where exception occured (dr.watson). It's very helps to find trouble place. And in that case we have choice: i can write catch(...) inside my thread function and catch them all, or skip some of them. -- Best regards, maq mailto:maq@mail.ru