Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Subject: Re: pthread_cond_timedwait accurate to one second only From: "Timothy C Prince" To: pgarrone AT linuxmail DOT org CC: cygwin AT cygwin DOT com Date: Mon, 25 Aug 2003 15:26:14 +0000 X-Sender: tprince MIME-Version: 1.0 Message-ID: <1061825174.bee59ae0tprince@myrealbox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h7PFQYI25452 -----Original Message----- From: "peter garrone" To: cygwin AT cygwin DOT com Date: Mon, 25 Aug 2003 15:42:52 +0800 Subject: pthread_cond_timedwait accurate to one second only Hi. I would like to use this function down to 10 milliseconds accuracy if possible. However upon looking at winsup/cygwin/thread.cc, it uses the function "ftime" and the millisecond field is ignored. All the examples in the winsup testsuite also generally check to 5 seconds only. Is there any inherent reason why finer timing would not work? _____________________________________________________ In order to avoid going to newlib and implementing Windows GetLocalTime() calls in gettimeofday(), we made the -mwin32 build option invoke the API milliseconds call directly in the g77 runtime libf2c/libU77/datetime_.c. I think the "inherent reason" is the perceived awkwardness in making library calls pick up milliseconds on Windows, while leaving the lower order part of the microseconds field undetermined. My documentation on ftime() says it is obsoleted by gettimeofday(). Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/