Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020714220533.02e2ec00@pop3.rowe-clan.net>
Date: Sun, 14 Jul 2002 22:36:49 -0500
To: <rbb@covalent.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: RE: more notes on the apr_time_t issue
Cc: "'William A. Rowe, Jr.'" <wrowe@rowe-clan.net>,
        "'Aaron Bannert'" <aaron@clove.org>, <dev@apr.apache.org>
In-Reply-To: <00b101c22baa$ed124f30$0a01230a@KOJ>
References: <5.1.0.14.2.20020714153639.00b94680@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:54 PM 7/14/2002, Ryan Bloom wrote:
> > apr_time_xmake(sec, xsec);
> >
> > So xsec can be an nsec, usec or msec, depending on the app.
> > So WHAT?  They all follow an incredibly simple pattern.
>
>BTW, nsec is completely bogus.  There isn't an OS that I know of that
>reports nsec intervals.  Windows comes the closest with 100 nsec chunks,
>but that isn't nsec.  Having a macro that purports to report nsecs when
>NONE of our OSes can accurately report them is bogus.

So we drop nsec.  Big hairy deal.  It was just there as a math proof
of how to move about too many bits without losing precision.

Evidently Justin has found the second use case.  And if you are trying
to preserve time when udate'ing() on a file, you better know the original
time if you want to roundtrip.

>Four macros, by four different scales, equals 16 macros.  And, at the
>end of the day, the values stored are useful once you leave APR.

s/the values/none of the values/  ...  I presume.

>BTW, the apr_time_xmake(sec, xsec) macro is completely wrong IMHO.  In
>order to use it, I need to provide multiple values, but that doesn't
>make any sense, because we have four time scales.  Either provide a
>single value, or four.  Two just doesn't make sense.

You are being somewhat goofy or clueless.  I have two numbers.  Perhaps they
are seconds and microseconds, perhaps seconds and milliseconds.  Both are
very common.  In either case, you want an APR time.  Plug them both in
(from a tm struct, or whatever) and you get a result.

If the name apr_time_sec_usec_make(secs, usecs) makes more sense, we
can name it that.  Honestly, I figured a macro named apr_time_umake
requiring two arguments would take sec and usec.  If that isn't apparent, then
we name it better.  It's still much better than;

apr_tm = apr_time_from_sec(t.sec);
apr_tm += apr_time_from_usec(t.usec);

... I believe.

> > I have no problem fixing the ambiguity between _xsec_get and _to_xsec,
> > since the difference is subtle.  Perhaps apr_time_frac_to_xsec(time)
> > instead of _xsec_get?  (saying, only the fractional portion of a
>second?)
>
>Perhaps an example of the difference, because I don't see it.

Skipping the algebraic differences?  Simply you have two things;

Give me a timeout in milliseconds == apr_time_as_msec(apr_time_value)

Fill me a tm structure;
     tm.sec == apr_time_sec_get(apr_time_value)
     tm.usec == apr_time_usec_get(apr_time_value)

There is a big difference here, the first apr_time_as_msec gave you the
WHOLE time, integers and fraction of a second.  The second case, _get,
got you only the intregal seconds and the intregal usec fraction of a second.

If you want _frac_ in the macro, that's fine.

>Quite honestly, I have tried to ignore the macro-ization that has been
>done recently, although whenever I see ten commits in a row to implement
>them, I do curse loudly.  I would never use those macros with today's
>implementation, because they just get in the way of me knowing what is
>going on.

Sorry you find them obtuse.  Perhaps Aaron's pointer to the "Veto early,
veto often, prevent people from wasting their efforts" shouldn't be changed
at all.

I'd suggest you snooze, you lose, but of course this is only two weeks old,
not two years old.

>If it is only happening in one place, then only store it in one format.
>I don't care if it is internals or externals either.  Data duplication
>is a bad idea unless the performance improvement is massive.  Every
>other place we have had this kind of data duplication in APR before, it
>has caused bugs.  And yes, the original implementation for APR's time
>code had this kind of duplication on Windows to solve the exact problem
>that you are trying to solve.

Well, I've determined we have a handful of timeout inconsistencies
on Windows right now, since we don't keep track of both.

> > I don't mean to sound harsh here, but we've been working in this direction
> > for three weeks or so, much longer than the current debate.  I'm just 
> asking
> > myself where you've been while Brian Pane and I were introducing the new
> > macros and fixing up the code in preparation for initial profiling and 
> whatever
> > potential change.
>
>For the most part, I have been busy and not watching too closely.  When
>the macros were added, I assumed I could ignore them.  Now I can't,
>because they are the only way that the time code can work.

If we keep APR_TIME_BUSEC_PER_SEC, or some flavor thereof (less
specific perhaps, like APR_TIME_UNITS_PER_SEC) then you could
continue to code as you have.

Bill