apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From field...@apache.org
Subject cvs commit: apr STATUS
Date Fri, 12 Jul 2002 00:30:59 GMT
fielding    2002/07/11 17:30:59

  Modified:    .        STATUS
  Log:
  more junk
  
  Revision  Changes    Path
  1.149     +25 -1     apr/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/apr/STATUS,v
  retrieving revision 1.148
  retrieving revision 1.149
  diff -u -r1.148 -r1.149
  --- STATUS	12 Jul 2002 00:13:53 -0000	1.148
  +++ STATUS	12 Jul 2002 00:30:59 -0000	1.149
  @@ -98,6 +98,10 @@
   
         [wrowe: deltas require NO definition of the scale.]
   
  +        [fielding: That's nonsense. What does overflow mean?  What are you
  +         going to do when you print?  How do you interface with other library
  +         routines?  Scale always matters for scalars.]
  +
         [fielding: If not, then we should be storing time in a 
          structure with separate fields in order to have better precision 
          with less code.]
  @@ -106,6 +110,10 @@
          a dead horse... compositing and breaking apart for each simple deltas 
          (the most common case) is too costly.  Scalars are the only clean
          answer - and you do not need to know scale to do addition/subtraction.]
  +
  +        [fielding: Dean argued that in general.  I argue that httpd never
  +         does time arithmetic other than in seconds and second-comparisons.
  +         Microseconds are therefore harmful to httpd.]
          
         [fielding: In any case, time_t ==> seconds because time_t is guaranteed
          by POSIX to be a scalar quantity for arithmetic operations.
  @@ -115,6 +123,9 @@
   
         [wrowe: read code.]
   
  +        [fielding: I read it.  I know exactly which functions from httpd
  +         that I wrote were subsequently broken when they were moved into APR.]
  +
         [fielding: Meanwhile, the only reason we have this stupid debate is 
          because wrowe insists that time_t is 32 bits and therefore dies in 2038.
          In fact, time_t is 64 bits on 64bit NT, Linux, OSF, and probably
  @@ -128,6 +139,11 @@
               in addition to seconds.  Why do you want to throw away the
               microseconds?!!]
   
  +              [fielding: Sorry, I missed them:
  +                  86 calls to apr_time_now()
  +                  32 calls to time()
  +               +1 to making time consistent.]
  +
          We don't use them.  We don't even have display functions for them.
          We have to do a stupid conversion every time we actually do something
          useful with time in order to support somebody's wet dream of a
  @@ -139,6 +155,14 @@
          2. no, on 64 bit WinNT time_t remains 32 bits, as do all ints.
          3. several apps include flood and ab require usec resolution.
          4. Posix timeval structures use sec/usec resolution.]
  +
  +     [fielding: 1. POSIX requires it to be long, so largest native int.
  +       2. Microsoft claims otherwise, but it is still vaporware anyway.
  +       3. POSIX always stores them as separate integers.
  +       4. Benchmarks are meaningless unless they average over hundreds
  +          of requests, which requires double floats (not time intervals).
  +       5. +1 for using struct tm everywhere.
  +       6. No.]
   
   RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
   
  
  
  

Mime
View raw message