This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: posix time functions
Nick Garnett wrote:
David Brennan <david@brennanhome.com> writes:
I was also wavering if the new term needed to be protected by a
semaphore. I decided against it. (Due to the fact that an invalid
gettime would have relatively low risk of creating problems combined
with relative number of times that the time will be set within an
application.) However, if you feel it is necessary, I will add one.
This is good as far as it goes. However, you still need to make some
changes in timer_settime() and timer_gettime(). These need to add or
subtract the real_time_offset as appropriate. Consider the following
code for example:
clock_gettime(CLOCK_REALTIME, &ts.it_value);
ts.it_value.tv_sec += 5;
timer_settime( timer, TIMER_ABSTIME, &ts, NULL );
Hmmm, I did not think of people accessing it that way, I assumed that
clock_gettime would only be used to get a calendar time. I had assumed
(probably incorrectly) that to get the current real-time, one would use
something like cyg_current_time(). Solving it like you suggest is only
going to bring back the problem that I initially had. I haven't looked
at the API closely, would it be safe to assume the code written above
could be written using timer_gettime first? The idea was that if you
change the calendar time, you do not want all of the absolute timers to
change their alarm times. In my application, I will set the time using a
pseudo NTP type function about once an hour. Due to the timing
resolution of the i386 platform with a base clock frequency of 1 kHz, I
will set the time backwards about 200 mSec each hour. This causes all
of my alarms to get delayed by an extra 200 mSec. Therefore, I want to
be able to change the time that posix thinks it is without affecting any
"real" real-time timers, none of which are set from the clock_gettime
function.
.
I suspect that some changes will also need to be made in
pthread_cond_timedwait() and similar functions, so that the following
would work:
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += 5;
rc = 0;
while (! mypredicate(&t) && rc == 0)
rc = pthread_cond_timedwait(&cond, &mutex, &ts);
To avoid planting ifdefs all over the code I think that the offset
adjustment should be done in macros. These can be defined to do
nothing in the case where the option is disabled.
Strictly, each time the clock is changed, all timers, delays and
timeouts based upon it should be re-evaluated. However, this is
complicated and we don't currently preserve all the information
necessary to do this.
I think my comment above applies to this also.
The patch seems to have been corrupted a little, sending it as an
attachment should solve this.
I can resend it as an attachment when we get this figured out. (Is it
readable?)
David Brennan
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss