[boost] Re: problems with boost::thread

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-04-19 01:28:59

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).

> 
> > 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...

> 
> On the other hand, letting exceptions escape from the thread function
> is also bad.
Bad = undefined or some other reason?

> 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? 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++.

Regards
Darryl.