Michael Glassford <glassfordm <at> hotmail.com> writes:
"Darryl Green" <darryl.green <at> unitab.com.au> wrote in message 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?
Well, xtime currently has the interface for it, but no impl for anything other than TIME_UTC. I assume TIME_MONOTONIC etc are there for future extension. The posix times() function's return value represents a form of monotonic time since a fixed point in time no later than the process start time. This should provide a widely available form of monotonic time information (limited range though). On posix pthreads systems with the relevant options supported, there shouldn't be a problem making xtime support whatever subset of clocks the system supports. That said, is this the right thing to do? xtime is a very "c" sort of a creature and seems to lack basic type safety. Wouldn't it be better to have a different time type for each clock type? A common duration type could be used. One way or another, changing the time type is easy, but the actual timed wait implementation is harder, as evidenced by maq's test on windows. The root of this lies in the fact that xtime's TIME_UTC is "wallclock" time, while the relative time used by the windows Wait.. functions is a "tick count" (afaik) and isn't affected by changing the system time. Unless windows supports some form of timer event that uses "wallclock" time there doesn't seem to be a way to fix this. Posix systems should act consistently (CLOCK_REALTIME used throughout) afaik. The existing windows code would work fine (except for the race/lack of precsion issue that already exists in converting from an absolute time to a duration) using a monotonic timer using the same tick count as the built-in timeout functions. The high resolution timer doesn't seem in any way usefull here as there is no way of scheduling a timeout to a higher precision than the tick period anyway. For posix compatiblity, the type of clock used needs to be an attribute of the condition variable. It isn't possible to have each timed_wait use a different clock. Once again, it seems that this should be a template parameter, not a runtime option. I think nptl + glibc 2.3.3 on linux supports the _POSIX_CLOCK_SELECTION option needed fort the above to work, but I haven't upgraded yet. I'd be happy to have a crack at implementing something and testing on that platform once I do. Does the general direction sound ok? Basically make a timer that takes the clock type as a policy and make classes that support timeouts (condvars, mutexes so far) templated on the timer type? Provide partial specializations for for things like full pthreads-based clock selection, but can allow (as per current windows impl) a fallback to using a duration based timeout running whatever clock the OS uses for timeouts?
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?
Sorry, I don't know. Sounds horrible.
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.
Ok. But then that gets into the whole "isn't everything?" when it comes to C++ and threads.
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:
[snip]
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.
[snip my long comment] Ah. I couldn't see how it fixed anything for maq. I probably didn't really need to make quite so much noise. Just "not any better" would have done I guess.
Thanks for your comment.
No problem. Regards Darryl.