cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: GetTickCount vs QueryPerformanceCounter

From: Igor Novoseltsev <IgorN_at_radvision.com>
Date: Thu, 27 May 2010 14:22:51 +0300

> > I have been using it in Windows 95, 98, NT, 2000 and XP. It seems to
exist
> > in most moderately modern Windows systems, but read this first:
> > http://www.virtualdub.org/blog/pivot/entry.php?id=106

The quote from this article claims: "If you don't really need high
precision, you can use GetTickCount()".
The libcurl needs precision of 1ms, which is not provided by the
GetTickCount (as it was shown by the sample code).

> One thing that also struck me is that libcurl already has a provision
(since
> 7.18.2) that makes it add 1000 microseconds to the check time,so if
the
> timeout fires off less than 1 millisecond before the actual timeout

The difference between GetTickCount and QueryPerformanceCounter can be
larger than 1 msec.
In the tests performed using the sample code, the average gap was 4
msec.

> be a problem. Can you (Igor) confirm that you're using at least this
version

I used 7.20.0.

> So a question:
>
> If curl_multi_socket_action() is called with a timeout action, and it
finds
> no
> timeout action to run for the particular handle since none has yet
expired.
> Wouldn't it make sense if the function would call the timout callback
(again)
> and inform the app about the still existing timeout?

Good idea! To implement it all you need is to comment out the following
check in the update_timer():

if(Curl_splaycomparekeys(multi->timetree->key, multi->timer_lastcall) ==
0)
   return 0;

The problem is that this check was added to solve some other problem, as
it is explained by following comment in code:

  /* When multi_timeout() is done, multi->timetree points to the node
with the
   * timeout we got the (relative) time-out time for. We can thus easily
check
   * if this is the same (fixed) time as we got in a previous call and
then
   * avoid calling the callback again. */

> Would it help this situation, or would it create a crazy busy loop
since the
> app will continuously believe the timeout has expired?

It helps in my case. My app runs additional timer for the " still
existing timeout " interval.
Note, this additional timer may not liquidate the QPC-GetTickCount gap.
It may take 2-4 iterations to get the libcurl to agree that the
requested timeout occurred.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-05-27