From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3260 invoked by alias); 22 Oct 2004 09:45:36 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 3231 invoked from network); 22 Oct 2004 09:45:34 -0000 Received: from unknown (HELO anchor-post-33.mail.demon.net) (194.217.242.91) by sourceware.org with SMTP; 22 Oct 2004 09:45:34 -0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-33.mail.demon.net with esmtp (Exim 4.42) id 1CKvzn-0004WD-Aa; Fri, 22 Oct 2004 09:46:03 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 27499DD79; Fri, 22 Oct 2004 10:45:33 +0100 (BST) To: David Brennan Cc: ecos-patches@sources.redhat.com, eCos Discuss References: <415CDA2C.8080701@brennanhome.com> <41788AB3.6030807@brennanhome.com> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Fri, 22 Oct 2004 12:40:00 -0000 In-Reply-To: <41788AB3.6030807@brennanhome.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] posix time functions X-SW-Source: 2004-10/txt/msg00354.txt.bz2 David Brennan 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