> -----Original Message-----
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 13, 2002 3:05 PM
> To: Bill Stoddard
> Cc: APR Development List
> Subject: RE: cvs commit: apr-site versioning.html
>
>
> On Tue, 13 Aug 2002, Bill Stoddard wrote:
>
> >
> > > > >I have a better question. Has anybody come up with a design
> > > that we can
> > > > >agree on for this? If there is no design, then we really
> > > can't solve the
> > > > >problem quickly. The last I saw about this issue, nobody
> > > agreed on how to
> > > > >fix it, or even that there was a real problem.
> > > > >
> > > >
> > > > There were a few promising solutions, but all of them had one
> > > > technical problem or another. Basically, each of the proposals
> > > > performed well for some set of operations but poorly for at least
> > > > one other operation that might be important to some application.
> > > >
> > > > Toward the end of that last round of discussions, I thus proposed
> > > > that APR get out of the business of managing microseconds:
> > > >
> > > > http://marc.theaimsgroup.com/?l=apr-dev&m=102678180413988
> > > >
> > > > I'm interested in hearing people's comments on that proposal.
> > >
> > > Doesn't that completely ignore Cliff's message early in this
> thread that
> > > specifically stated that he needed microsecond resolution?
> >
> > Go read the post in detail. microsecond resolution is
> available. It is just
> > stored in a different field.
> >
> > I am +0 on the proposal pending further mastication :-)
>
> That is in Apache, which has nothing to do with APR. The proposal
> specifically states that APR will stop dealing with microseconds, which
> makes it useless for an app outside of httpd that wants microsecond
> resolution.
>
> Ryan
>
I was basing my comment on this snip from the note:
apr_time_now() returns a time_t, but it also returns
the microseconds as a separate value for apps that need
them:
apr_status_t apr_time_now(apr_time_t *sec, apr_uint32_t *usec);
I don't know how to address your concern.
Bill
