On Feb 20 19:15, 109224573 via Cygwin wrote:
> this code works on Linux, but not msys2:
>
> #include
> #include
> int main() {
> struct timezone tz;
> puts("a");
> gettimeofday(NULL, &tz);
> puts("b");
> }
>
>
> I
this code works on Linux, but not msys2:
#include
#include
int main() {
struct timezone tz;
puts("a");
gettimeofday(NULL, &tz);
puts("b");
}
I guess the reason would be
winsup/cygwin/times.cc
extern "C" int
gettimeofday (struct timeval *__
Hi Stephen,
On Jun 19 19:30, Stephen Sheldon wrote:
> Sometime in the past several months MPlayer stopped compiling for Cygwin.
> There
> was a complaint about gettimeofday not being defined. The failing file did
> include sys/time.h, which contains a definition. I found one si
Sometime in the past several months MPlayer stopped compiling for Cygwin. There
was a complaint about gettimeofday not being defined. The failing file did
include sys/time.h, which contains a definition. I found one similar report
on the Cygwin mailing list. I noticed that MPlayer was putting
On 17/11/14 12:41, Corinna Vinschen wrote:
On Nov 15 16:56, David Stacey wrote:
I'm not convinced that the test is valid. Poco seems to be making
assumptions about clock_gettime() and gettimeofday() that simply aren't
guaranteed to hold - but obviously do in Fedora at least. Fo
e
> Foundation testsuite.
>
> The Poco code uses two clock classes, one that uses clock_getttime() and the
> other uses gettimeofday(). The test creates two timestamps using the two
> clock classes, both 0.1 seconds in the future. clock_gettime() is polled
> repeatedly until the time
, one that uses clock_getttime() and
the other uses gettimeofday(). The test creates two timestamps using the
two clock classes, both 0.1 seconds in the future. clock_gettime() is
polled repeatedly until the timestamp is reached. Then the other
timestamp is checked (using gettimeofday()) to
>The most recent snapshot has this change as well as all of the stuff
>Corinna has done today:
>
>http://cygwin.com/snapshots/
Thanks for the fix! I've checked the most recient snapshot and found
out that everything works fine!
--
Problem reports: http://cygwin.com/problems.html
FAQ:
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
>> >> ge
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. Bu
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
> >> se
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 a
> 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
> gett
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
with my test of gettimeofday in cygwin it appears to be counting in
milliseconds
rather than microseconds.
so I had a look at where it is coded, /winsup/cygwin/times.cc
...
gettimeofday (struct timeval *tv, void *tzvp)
{
struct timezone *tz = (struct timezone *) tzvp;
static bool tzflag
On Mon, Feb 19, 2007 at 12:52:10PM -0800, Shankar Unni wrote:
> Andrew Makhorin wrote:
>
> >{ double t0 = get_time(), t1 = get_time();
>
> [Maybe OT?]
>
> 1. I can't remember if C guarantees that comma-separated *declarations*
> are initialized in order or not.. And to think I used to be
Andrew Makhorin wrote:
{ double t0 = get_time(), t1 = get_time();
[Maybe OT?]
1. I can't remember if C guarantees that comma-separated *declarations*
are initialized in order or not.. And to think I used to be an ANSI C
guru :-(.
2. The reason that the "t0 > t1" fails, but t0 and t
On 16 February 2007 13:36, Andrew Makhorin wrote:
> The irony is that I usually give the same standard explanation about
> floating-point to people who do not understand that :) *Unfortunately*,
> you are right, and the difference really appears because the second
> value returned by get_time bei
On 2/16/07, Andrew Makhorin wrote:
Nevertheless, you agree that if t0 > t1 then t0 - t1 cannot be exact
zero in *any* floating-point model, don't you? Even if optimization is
used, the compiler must not arbitrarily change the precision of the
same floating-point variable.
The -ffloat-store com
inary places) relative to each other in the mantissa.
Yes, that is. I just tried to reproduce a bug concerning gettimeofday,
and computing the time in such way was not my intension.
>
> Floating point representation should never be used for something for
> which you need an accurate
--On 16 February 2007 04:12 +0300 Andrew Makhorin <[EMAIL PROTECTED]> wrote:
double get_time(void)
{ struct timeval tv;
gettimeofday(&tv, NULL);
return (double)tv.tv_sec + 1e-6 * (double)tv.tv_usec;
}
I would be suspicious of floating-point rounding errors here for th
without the conversions.
>
> Because I could not reproduce the bug concerning gettimeofday out of
> a complex program where it is used. Probably it works correctly. But
> then I would like to know why comparison of two floating-point numbers
> leads to different results: t0 is *exact
> I would be suspicious of floating-point rounding errors here for the
> original problem you described. Why don't you try a test case that just
> checks if one tv is ever less than a previous tv, without the conversions.
Because I could not reproduce the bug concerning gettime
Andrew Makhorin wrote:
> double get_time(void)
> { struct timeval tv;
> gettimeofday(&tv, NULL);
> return (double)tv.tv_sec + 1e-6 * (double)tv.tv_usec;
> }
I would be suspicious of floating-point rounding errors here for the
original problem you described.
I would like to add to my previous message that the test fails
*sometimes*, approx. once for 7-8 runs.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
>>>I detected a strange bug in the standard function gettimeofday.
>>>It *sometimes* reports the time which being expressed as the integer
>>>number of milliseconds is *less* than the time obtained *earlier* with
>>>the same function.
>>If you mean th
Andrew Makhorin wrote:
>> Hi,
>>
>> I detected a strange bug in the standard function gettimeofday.
>> It *sometimes* reports the time which being expressed as the integer
>> number of milliseconds is *less* than the time obtained *earlier*
>> with the same fu
Andrew Makhorin wrote:
I detected a strange bug in the standard function gettimeofday.
It *sometimes* reports the time which being expressed as the integer
number of milliseconds is *less* than the time obtained *earlier* with
the same function.
...how often is "often"? Also what
e
OP, I haven't ever seen this behavior from gettimeofday.
--
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscrib
On Mon, Feb 12, 2007 at 11:00:38AM +0800, Carlo Florendo wrote:
>Andrew Makhorin wrote:
>>Hi,
>>
>>I detected a strange bug in the standard function gettimeofday.
>>It *sometimes* reports the time which being expressed as the integer
>>number of milliseconds
Andrew Makhorin wrote:
Hi,
I detected a strange bug in the standard function gettimeofday.
It *sometimes* reports the time which being expressed as the integer
number of milliseconds is *less* than the time obtained *earlier* with
the same function.
If you mean that you call gettimeofday
On 2/11/07, Christopher Faylor wrote:
On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote:
>Hi,
>
>I detected a strange bug in the standard function gettimeofday.
>It *sometimes* reports the time which being expressed as the integer
>number of milliseconds is *less
On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote:
>Hi,
>
>I detected a strange bug in the standard function gettimeofday.
>It *sometimes* reports the time which being expressed as the integer
>number of milliseconds is *less* than the time obtained *earlier* with
>
Hi,
I detected a strange bug in the standard function gettimeofday.
It *sometimes* reports the time which being expressed as the integer
number of milliseconds is *less* than the time obtained *earlier* with
the same function.
The expression 100 * tv.tv_sec + tv.tv_usec is calculated in
64
win, you
can't just go mixing bits and pieces of each. They use radically
different C runtimes.
If you want to use mingw, you need to use -mno-cygwin. The include
paths will be adjusted accordingly.
This is quite a red herring though, because there's no need to use mingw
to call gettimeo
i,
I've a program written for SUSE linux. The compile fails at the same
place each time while referencing gettimeofday. I compile like this
gcc -I/usr/include/mingw -I/usr/include/mingw/sys GoCart_v04.c -lm
I compile with and without the -I included dirs and still have the
problem
n another function ?
>
> TIA
>
> Neto
> brazil
>
> -Original Message-
> From: Igor Pechtchanski
> Sent: Wednesday, March 31, 2004 1:25 PM
> To: Neto, Antonio Jose Rodrigues
> Cc: cygwincygwincom
> Subject: RE: SPAM: Re: gettimeofday() similar function
>
>
On Wed, 31 Mar 2004, Neto, Antonio Jose Rodrigues wrote:
> Ok, but when I try to compile using -mno-cygwin that is not working.
>
> Why?
>
Isn't it obvious? gettimeofday is in Cygwin. You asked for no Cygwin
(ie. mingw). Look at www.mingw.org for details as this is now off
How do I resolve this?
-Original Message-
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 1:30 PM
To: Neto, Antonio Jose Rodrigues
Cc: [EMAIL PROTECTED]
Subject: RE: SPAM: Re: gettimeofday() similar function
On Wed, 31 Mar 2004, Neto, Antonio Jose
ednesday, March 31, 2004 1:25 PM
> To: Neto, Antonio Jose Rodrigues
> Cc: cygwincygwincom
> Subject: SPAM: Re: gettimeofday() similar function
>
>
> On Wed, 31 Mar 2004, Neto, Antonio Jose Rodrigues wrote:
>
> > Hi Brian,
> >
> > Do you know?
> >
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 1:25 PM
To: Neto, Antonio Jose Rodrigues
Cc: [EMAIL PROTECTED]
Subject: RE: SPAM: Re: gettimeofday() similar function
Neto,
Have you actually tried?
Igor
P.S. Please configure your mailer to not quote raw e-mail addresses in
your repli
Ok, but when I try to compile using -mno-cygwin that is not working.
Why?
-Original Message-
From: Brian Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 1:25 PM
To: Neto, Antonio Jose Rodrigues
Cc: [EMAIL PROTECTED]
Subject: SPAM: Re: gettimeofday() similar function
On
Jose Rodrigues wrote:
> Hi Brian,
> Do you know?
> TIA
> neto
>
> -Original Message-
> From: Brian Ford
> Sent: Wednesday, March 31, 2004 1:18 PM
> To: Neto, Antonio Jose Rodrigues
> Cc: cygwincygwincom
> Subject: SPAM: Re: gettimeofday() similar function
>
On Wed, 31 Mar 2004, Neto, Antonio Jose Rodrigues wrote:
> Hi Brian,
>
> Do you know?
>
What I was trying to say is that gettimeofday *is* in Cygwin.
Please do not quote raw email addresses in replies. It just feeds the
spam havesters.
> -Original Message-
> From
Hi Brian,
Do you know?
TIA
neto
-Original Message-
From: Brian Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 1:18 PM
To: Neto, Antonio Jose Rodrigues
Cc: [EMAIL PROTECTED]
Subject: SPAM: Re: gettimeofday() similar function
On Wed, 31 Mar 2004, Neto, Antonio Jose
On Wed, 31 Mar 2004, Neto, Antonio Jose Rodrigues wrote:
> Hi All,
>
> Could you help me?
>
> What the similar function in the cygwin?
>
Um..., (scratches head, looks puzzled), gettimeofday() maybe?
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Sy
Hi All,
Could you help me?
What the similar function in the cygwin?
TIA
Best Regards
neto
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://
Windows API call to compensate for this lack in cygwin
> gettimeofday().
>
I think your information may be out-of-date. gettimeofday()
appears to currently have approximately one to two millisecond resolution
on XP. What do you see?
--
Brian Ford
Senior Realtime Software Engineer
VITAL -
At 11:00 PM 2/28/2004, Peng Yu wrote:
What is AFAIK?
How I can fall back on the Windows API?
The cygwin specific code in the g77 date_and_time() source code shows use
of the Windows API call to compensate for this lack in cygwin
gettimeofday(). http://cygwin.com/acronyms/Way back in the
What is AFAIK?
How I can fall back on the Windows API?
Peng
- Original Message -
From: "Tim Prince" <[EMAIL PROTECTED]>
To: "Peng Yu" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, February 28, 2004 10:54 PM
Subject: Re: gettimeofday
At 09:53 PM 2/28/2004, Peng Yu wrote:
Hi,
I want read the manual of the C++ function gettimeofday. But I can't
find it. I'm not sure whether I installed it or not. Can somebody help me?
Thanks.
Not part of C++ AFAIK. It's a posix function with C binding. Apparently,
th
n/)
Greg
_
Hi,
I want read the manual of the C++ function gettimeofday. But I can't
find it. I'm not sure whether I installed it or not. Can somebody help me?
Thanks.
Best wishes,
Peng
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem
Peng Yu wrote:
> I want read the manual of the C++ function gettimeofday. But I can't
> find it. I'm not sure whether I installed it or not. Can somebody help me?
That function is a C function, and it's part of libc, the standard C
library. "info libc" is
Hi,
I want read the manual of the C++ function gettimeofday. But I can't
find it. I'm not sure whether I installed it or not. Can somebody help me?
Thanks.
Best wishes,
Peng
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://
found that the gettimeofday() and ftime() functions do not always
return the correct system time as reported by Windows. The time()
function, however, always remains in sync with Windows time. This
discrepancy occurs when an application is started, then the Windows
system time changes, then the ap
On Thu, Jul 17, 2003 at 05:53:02PM -0400, Larry Hall wrote:
>Chris Church wrote:
>
>>I'm using version 1.5.0 of the cygwin1.dll on Windows 2000
>>Professional. I've also seen the problem described below on earlier
>>versions of cygwin (1.3.22).
>>
>&g
On Thu, Jul 17, 2003 at 04:06:15PM -0400, Chris Church wrote:
>Is this a known issue with Cygwin,
Yes
>and are there any patches available?
No
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to [EMAIL PROTECTED]
and be p
Chris Church wrote:
I'm using version 1.5.0 of the cygwin1.dll on Windows 2000
Professional. I've also seen the problem described below on earlier
versions of cygwin (1.3.22).
I've found that the gettimeofday() and ftime() functions do not always
return the correct system time
I'm using version 1.5.0 of the cygwin1.dll on Windows 2000
Professional. I've also seen the problem described below on earlier
versions of cygwin (1.3.22).
I've found that the gettimeofday() and ftime() functions do not always
return the correct system time as reported by Win
Rob Siklos wrote:
Does anyone know if Windows provides something similar? If so, how would I
access it from my program?
The best thing would be to visit http://msdn.microsoft.com and read the
library (the Win32 SDK).
There have also been various attempts to provide "very thin" (usually
partial
> >My first idea: Windows doesn't provide gettimeofday.
>
> Bingo.
Oh- that's too bad.
Does anyone know if Windows provides something similar? If so, how would I
access it from my program?
Thanks a lot,
Rob.
- Original Message -
From: "Christopher Fay
On Mon, Mar 31, 2003 at 10:36:40AM -0500, Rolf Campbell wrote:
>Rob Siklos wrote:
>>Hello,
>>
>>I am trying to compile the following trivial program:
>>
>>
>>#include
>>#include
>>
>>int main()
>>{
>> struct timeva
Rob Siklos wrote:
Hello,
I am trying to compile the following trivial program:
#include
#include
int main()
{
struct timeval tv;
gettimeofday(&tv, NULL) ;
printf("%ld %ld\n", tv.tv_sec, tv.tv_usec);
return 0;
}
When I use gcc with no options, everyth
Hello,
I am trying to compile the following trivial program:
#include
#include
int main()
{
struct timeval tv;
gettimeofday(&tv, NULL) ;
printf("%ld %ld\n", tv.tv_sec, tv.tv_usec);
return 0;
}
When I use gcc with no options, everything works fine. How
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor wrote:
> On Mon, Jan 13, 2003 at 09:55:15PM -0800, Fish wrote:
> >
> >Is there any reason why Philip Aston's 6 Jul 2002 patch to
> >gettimeofday et. al. logic to correct for WM_POWERBROADCAST event
On Mon, Jan 13, 2003 at 09:55:15PM -0800, Fish wrote:
>
>Is there any reason why Philip Aston's 6 Jul 2002 patch to
>gettimeofday et. al. logic to correct for WM_POWERBROADCAST events
>(PBT_APMRESUMESUSPEND, PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMECRITICAL)
>hasn't mad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any reason why Philip Aston's 6 Jul 2002 patch to
gettimeofday et. al. logic to correct for WM_POWERBROADCAST events
(PBT_APMRESUMESUSPEND, PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMECRITICAL)
hasn't made it into the sources
ficed accuracy for precision. Others have already pointed this
out and after a google/msdn search I am now convinced.
I think the best we can probably do is to use the multimedia timer
functions to get 1ms accuracy and I'll be redoing gettimeofday to use
those in the next couple of days.
I'
Christopher Faylor writes:
> On Sat, Jul 06, 2002 at 11:55:17AM +0100, Philip Aston wrote:
> >The list in thread.h is specific to a type, and intrusive. I used a
> >mutex to create my own thread-safe, non-intrusive list. I used pthread
> >mutexes instead of mutos since mutos must be allocated
On Sat, Jul 06, 2002 at 11:55:17AM +0100, Philip Aston wrote:
>The list in thread.h is specific to a type, and intrusive. I used a
>mutex to create my own thread-safe, non-intrusive list. I used pthread
>mutexes instead of mutos since mutos must be allocated statically.
What is wrong with allocat
Philip Aston writes:
* From: "Philip Aston"
* To: cygwin at cygwin dot com
* Date: Sat, 6 Jul 2002 11:55:17 +0100
* Subject: [PATCH] gettimeofday time travels V2
Hmm... ironically my mailer wasn't running against the patched DLL :-)
- Phil
--
Unsubscribe
re's a trace of suspend and resume whilst printing out the
results of gettimeofday:
D:\cygwin\cygdebug>gettimeofday-bug.exe
gettimeofday() returns 1021395726 857121
gettimeofday() returns 1021395728 860774
6 [win] gettimeofday-bug 5908 hires::wm_event: PWRBRDCST, wParam=0
11877
On Mon, May 13, 2002 at 09:56:58AM +0100, Philip Aston wrote:
>
>Philip Aston writes:
> > Christopher Faylor writes:
> > > The correct solution is to resync after events which cause the
> > > clock to stop.
> >
> > OK, I'll have a crack at this over the weekend following David's
> > hints.
>
>S
> -Original Message-
> From: Philip Aston [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 13, 2002 6:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] gettimeofday time travels
>
>
>
> Philip Aston writes:
> > Christopher Faylor writes:
> &g
Philip Aston writes:
> Christopher Faylor writes:
> > The correct solution is to resync after events which cause the
> > clock to stop.
>
> OK, I'll have a crack at this over the weekend following David's
> hints.
Short of some unexpected wParam values, which I'll track down, I now
have
Christopher Faylor writes:
> An NT only solution is not a solution.
I wasn't for a moment suggesting that it was.
> Syncing every "x" seconds also is not a solution.
>
> The correct solution is to resync after events which cause the clock to
> stop.
OK, I'll have a crack at this over the
Robert Collins writes:
> > -Original Message-
> > From: Philip Aston [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 16, 2002 6:30 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PATCH] gettimeofday time travels
> >
> >
&g
> -Original Message-
> From: Philip Aston [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 16, 2002 6:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] gettimeofday time travels
>
>
>
> cgf writes:
> > On Mon, Apr 15, 2002 at 09:58:48PM +010
cgf writes:
> On Mon, Apr 15, 2002 at 09:58:48PM +0100, Philip Aston wrote:
> >How about the attached quick and dirty fix?
>
> I'm sorry but I don't think a quick and dirty fix is justified if
> there are other alternatives. I haven't seen any other alternatives
> discussed yet.
Understoo
On Mon, Apr 15, 2002 at 09:58:48PM +0100, Philip Aston wrote:
>How about the attached quick and dirty fix?
I'm sorry but I don't think a quick and dirty fix is justified if there
are other alternatives. I haven't seen any other alternatives discussed
yet.
cgf
--
Unsubscribe info: http://c
(Resent with appropriate subject in case the original was missed in
the discussion thread).
How about the attached quick and dirty fix?
- Phil
2002-04-14 Philip Aston <[EMAIL PROTECTED]>
* times.cc (hires::usecs): Sync counter every ten minutes to
work around suspend bug
Ralf Habacker wrote:
> Lapo Luchini writes:
> > > isn't the time slice about 10ms. ?
> > Actually is between 15 and 16ms:
> > try 2: 437703512 - 437719512 = 16000
> > try 3: 437719512 - 437734512 = 15000
> Thats my result on a toshiba Satelitte Pro 4300 Laptop with win2000
> try 1: -347828856
37984512 = 15000
> try 20: 437984512 - 438000512 = 16000
>
Thats my result on a toshiba Satelitte Pro 4300 Laptop with win2000
habacker@BRAMSCHE ~/src/gettimeofday
$ ./a.exe
try 1: -347828856 - -347818856 = 1
try 2: -347818856 - -347808856 = 1
try 3: -347808856 - -347798856 =
^
> > the usual 15 milliseconds or so.
> >
> This is a output of the mentioned profiler. It say about a minimal time of about 1-2
>us. May the difference be
> caused by the cygwin.dll overhead ? (We're using the native functions, not
>gettimeofday(
ng)t.tv_usec)
int main() {
struct timeval tp;
unsigned long a, b;
unsigned int n = 1;
for(n=1; n<=20; n++) {
gettimeofday(&tp, 0);
a = TV2LONG(tp);
do {
gettimeofday(&tp, 0);
} while((b = TV2LONG(tp)) <= a);
printf("try %2d: %ld - %ld = %ld\n", n, a, b, b-a);
}
g
e
> caused by the cygwin.dll overhead ? (We're using the native functions, not
>gettimeofday()).
>
> [1828] EmptyTest count:100 time: (min) 1 [us] (max) 2 [us]
>(sum)169 [us]
On my machine it's actually 1.74us, but I made the test on some m
ntioned profiler. It say about a minimal time of about 1-2
us. May the difference be
caused by the cygwin.dll overhead ? (We're using the native functions, not
gettimeofday()).
[1828] EmptyTest count:100 time: (min) 1 [us] (max) 2 [us]
(sum)169 [us]
> I gu
>
> > >> Has anyone address this problem already. I have looked int the
> > >> cygwin and list and found the only topic
> > >http://sources.redhat.com/ml/cygwin/2001-12/msg00201.html
>
> In the attached file there is a "patch" for gettmieofday
t; http://cygwin.com/contrib.html
>
>Got it... I'll send one ASAP (-_- snail mail... when will a signed e-mail be accepted
>as "legal"? -_-)
>
>BTW: IANAL but the base for that gettimeofday() function is taken from Tim Prince's
>message and the file is "Cop
> As long as the calibration only occurs when someone is using
> gettimeofday, not on every cygwin1.dll load, then that sounds fine to
> me.
At the end of the mail there is some benchmarking to show PerformanceCounter
use is not that "slow" even in its setup (which is done
- snail mail... when will a signed e-mail be accepted
as "legal"? -_-)
BTW: IANAL but the base for that gettimeofday() function is taken from Tim Prince's
message and the file is "Copyright (c) 1994-1998 Larry McVoy." as the source reads...
--
Lapo 'Raist' Luchini
[EM
> As long as the calibration only occurs when someone is using
> gettimeofday, not on every cygwin1.dll load, then that sounds fine to
> me.
I wouldn't call it "calibration" is just a quick call to the old
gettimeofday() and, yes, it's done only on the first cal
===
- Original Message -
From: "Lapo Luchini" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 24, 2002 12:34 PM
Subject: Re: gettimeofday() does not returns usec resolution
> > Hmm. I do remember this patch. Can you submit this to
cygwi
On Thu, Jan 24, 2002 at 02:34:44AM +0100, Lapo Luchini wrote:
>> Do you have an assignment on file with Red Hat?
>
>Sorry but english knowledge doesn't let me understand "assignment on file", could
>you explain it to me with other words?
http://cygwin.com/contrib.html
cgf
--
Unsubscribe info:
idea.. please suggest =)
> Do you have an assignment on file with Red Hat?
Sorry but english knowledge doesn't let me understand "assignment on file", could
you explain it to me with other words?
> >---
> >int gettimeofday(struct timeval *tv, struct timezone *tz)
95 matches
Mail list logo
