apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: Why not POSIX time_t?
Date Mon, 15 Jul 2002 18:37:59 GMT
> >>    3. 64-bit shifts to get approximate seconds
> >>       (fast, but loss of accuracy)
> >>
> >>
> >
> >If you convert from microseconds to integer seconds (which is what httpd
> >requires), you loose -resolution- no matter how you do it. If
> the accuracy
> >you loose is smaller than the resolution, then what does it
> matter that you
> >loose some accuracy?
> >
> I think it's possible to see inaccuracies at the second level if
> we divide the current time_t by 2^20.  If not, then this concern
> vanishes.

Cliff demonstrates that there is significant loss of accuracy using just a
shift. I believe (faith? :-) that there is a simple solution to this. Don't
know what it is just now though...

> >I'd like to leave the struct/function renames off the table for
> now and just
> >discuss the technical details of the proposals... It was the
> intertwining of
> >the technical and esthetics of the naming convestions that made
> the previous
> >discussion difficult for me to follow.
> >
> I agree on this part.  Looking just at the proposals I've heard so
> far for the representation, and ignoring the naming issues, here's
> my attempt to enumerate the advantages and drawbacks of each
> representation:
>      * Scalar containing seconds since the epoch (like time_t):
>           Pros: Adequate for things that only need seconds,
>                 extracting seconds from this object has zero cost :-)
>           Cons: Not a general-purpose solution because it can't
>                 hold microseconds
>      * Scalar containing seconds and usec, encoded in the current
>        apr_time_t format:
>           Pros: Microsecond resolution
>           Cons: 64-bit multiplication and division ops are a
>                 performance problem in some important applications
>                 (like the httpd)
>      * Scalar containing seconds and usec, encoded in busec format:
>           Pros: Microsecond resolution, fast retrieval of seconds and
>                 microseconds

            fast retrival of binary seconds.  Need to convert to decimal to
pass on apr_poll, et. al., no?

>           Cons: None that I know of
>      * Struct containing seconds and usec as separate fields
>           Pros: Microsecond resolution, fast retrieval of seconds and
>                 microseconds
>           Cons: May take up more space (64-bit seconds plus 32-bit usec,
>                 compared to 64 bits for the whole object in some of
>                 the other designs), addition and subtraction are slower
>                 with a struct than with a scalar.
> Based on the technical merits of these designs (which I hope I've
> described accurately here--corrections welcome), I think the binary
> microseconds design is the best.

If it is not possible to efficiently extract accurate 1 second resolution
values from apr_time_t (decimal microseconds), then I agree. I am not quite
ready to conceed the point though.


View raw message