[boost] Re: problems with boost::thread

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-19 06:28:22

"Darryl Green" <darryl.green_at_[hidden]> wrote in message
news:loom.20040419T065628-962_at_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
>