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
