Having a time structure in the mpm keeping updated sec and uSEC
field could help performance for the web server.
It could replace most calls to apr_time_now() and apr_time_sec()
at run-time:
 
NetWare has its main thread resuming every 1000000 uSEC (1 sec)
to do the idle server maintenance.
The following code keep a local timeval structure, which could
return current time without having to call apr_time_now() every request.
 
Yes, only the tv_sec field is updated between call to gettimeofday().
 
Who cares about the uSEC precision anyway, apache is a web server,
 not a scientific clock application.
 
With the following function, calls to apr_time_now() in apache could
then be replaced with call to ap_time_now().
Or maybe just redefining apr_time_now() to ap_time_now() and
apr_time_sec() to ap_time_sec() will work for us.
 
I am thinking of using a set of functions like the following ones in the
NetWare mpm:
 
The synchonize_usec_clock() function is called every second by the main
thread when it resumes to do the idle maintenance.
It synchronizes the time fields every 5 seconds using the gettimeofday() function. 
 
Anyone sees problems with using a background thread to maintain
current time structure?
 
--- boc ---
static apr_int32_t mpm_clock_initialized;
static apr_time_t now;
struct timeval tv;
 
static void synchonize_usec_clock( void )
{
  static apr_int32_t counter;
 
  if (mpm_clock_initialized) {
    if(++counter > 4) {
      gettimeofday(&tv, NULL);
      now = tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
      counter = 0;
    }
    else {
      now += SCOREBOARD_MAINTENANCE_INTERVAL;
      tv.tv_sec++;
    }
  }
  else {
    gettimeofday(&tv, NULL);
    now = tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
    mpm_clock_initialized = 1;
  }
}
 
AP_DECLARE(apr_time_t) ap_time_now(void)
{
  if (mpm_clock_initialized) 
    return now;
  else
    return apr_time_now();
}
 
AP_DECLARE(apr_time_t) ap_time_sec(apr_time_t time)
{
  if (mpm_clock_initialized) 
    return tv.tv_sec;
  else
    return apr_time_sec(time);
}
--- eoc ---
 
Thank you,
 
Jean-Jacques 

Reply via email to