From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2004-04-19 08:58:41
"Michael Glassford" <glassfordm_at_[hidden]> writes:
> "Darryl Green" <darryl.green_at_[hidden]> wrote in message
>> 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
>> > 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
>> > this now, and there are some good reasons for specifying an
>> > time instead of a relative time. For example, if you use the
>> > recommended loop to wait on the condition variable, using an
>> > 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?
On Windows, you could use GetTickCount to do the timing, with
GetSystemTimeAsFileTime and SystemTimeToFileTime to get the limits --- e.g.
const SYSTEMTIME suppliedEndTime=...;
DWORD const initialTick=GetTickCount();
ULONGLONG const diff=reinterpret_cast<ULARGE_INTEGER const&)(endTime).QuadPart-
ULONGLONG const elapsedTicks=diff/10000;
>> > > 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
>> > 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
>> 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
>> 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?
I think this is always true under VC7.1, too. What you can do is call
set_unexpected_handler in the thread startup code, but I am not sure that this
is any better than catch(...)
As for what one should do with an unhandled exception in a thread... don't
know. Terminate sounds good, but you could do with a means of forcing other
threads to unwind.
-- Anthony Williams Senior Software Engineer, Beran Instruments Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk