Mail Archives: cygwin/2010/05/26/11:57:23
On Wed, May 26, 2010 at 11:56:20AM -0400, Christopher Faylor wrote:
>On Wed, May 26, 2010 at 04:25:43PM +0200, Corinna Vinschen wrote:
>>On May 26 10:22, Christopher Faylor wrote:
>>> On Wed, May 26, 2010 at 04:02:45PM +0300, "??? ??????" wrote:
>>> >> Hello. It seems that I found a problem with settimeofday() and
>>> >> gettimeofday() calls in a single context. The problem is that if we
>>> >> set a new time with settimeofday() call it completes succefully and
>>> >> system time is updated. But then if we try to get current time with
>>> >> gettimeofday() call it returns old time!
>>> >
>>> >I've looked into 'times.cc' and found that 'hires_ms gtod' timer
>>> >(which is used in gettimeofday()) is not reset with
>>> >'hires_ms::prime()' in settimeofday() after system call to Win32 API
>>> >SetSystemTime() function! I think this is the reason of described
>>> >behaviour.
>>>
>>> That sounds right. I'll check in a fix shortly.
>>
>>What happens in other, parallel processes which are calling gettimeofday
>>in a loop?
>
>I think we've always known that long-running cygwin processes did not
>deal with date/time changes correctly. However, for cygwin processes, in
>the same session at least, I think that sharing the gtod variable should
>work. In my limited testing it seems to.
>
>The most recent snapshot has this change as well as all of the stuff
>Corinna has done today:
>
>http://cygwin.com/snapshots/
Oh, I forgot to say: Thanks for the test case. Those are always extremely
appreciated.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -