Re: [boost] Re: problems with boost::thread

From: maq_at_[hidden]
Date: 2004-04-17 05:21:16

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_at_[hidden]