This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: posix time functions


David Brennan <david@brennanhome.com> writes:

> Here is my first attempt at a patch for this. I would have preferred
> putting the offset inside the Cyg_Clock class or the Cyg_RealTimeClock
> class, that way any "implementation" of gettime/settime could use
> that. However, I assumed you would not want the baggage in Cyg_Clock
> (even if it is CDL'able, it would end up in every instantiation of
> Cyg_Clock when configured enabled.) And there doesn't appear to be a
> "public" interface to the Cyg_RealTimeClock class that posix could
> call.

The POSIX layer is the correct place to do this, otherwise the
original problem of changing the time base under the feet of non-POSIX
timers would reoccur.

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


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. 


The patch seems to have been corrupted a little, sending it as an
attachment should solve this.

> Once this patch gets finalized, the same thing should be done to the
> uitron interface. I'd be willing to post the code, but I haven't go
> the slightest idea how to test it.

I wouldn't worry too much about uitron at present. I'm not sure there
are many users.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]