You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 2000/01/08 22:00:06 UTC
time overhaul
the time thread got me worked up enough i started writing code. i'm about
half way through overhauling the time representation in apr.
ap_time_t is a scalar again, and can be used almost exactly like time_t
would be used -- except that it's 64-bits and in units of microseconds.
ap_exploded_time_t is a structure containing all the human readable
fields.
one nice thing is that the apache core code looks more like 1.3 this way
than it did before... the portability layer is less obvious.
when i check it in windows will be broken... but it shouldn't be hard to
fix.
Dean
Re: time overhaul
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > There are no ap_get_os_*time functions.
>
> this seems to defeat the purpose of a portability layer... i'm confused.
One of the things that APR has always accepted, is that APR is not used in
every program throughout the world. One of the programs that we are not
used in, is PHP and perl. If we want mod_php and mod_perl to function
well with Apache 2.0, we need to make sure that they can easily go from
APR types to native OS types. If you look at apr_portable.h, every APR
type has a function that returns the native type. I believe this is
covered in APRDesign.
> yup i've a problem with it. think of ap_now() as a global variable rather
> than a function call please :)
>
Fine, I'll forget about the ap_now changes, but the ap_(get|put)os_*_time
functions are absolutely necessary, or we have made the entry to Apache
2.0 too high. I know php has their own portability layer, and they would
rather continue to use it until APR is more proven. If we don't make it
easy to port php to Apache 2.0, we are going to make entry too high.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: time overhaul
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 9 Jan 2000, Ryan Bloom wrote:
> > the other thing i'm thinking of doing is interval timers similar to
> > NSPR's. this would be used for things such as the poll timeout interval.
> > it would be a 64-bit microsecond-like thing as well.
er i should have said 32-bit.
> How is this different from the ap_time_t that you already implemented?
> What new functions would be added, what benefit does it give us that the
> ap_time_t doesn't already provide?
>
> Sorry, I don't see the need.
you can see the NSPR docs at
<http://www.mozilla.org/docs/refList/refNSPR/prinrvl.html#1007115>
the summary is that ap_time_t is a 64-bit absolute quantity based on an
epoch... and interval timers are 32-bit relative quantities.
ap_poll() and the network i/o stuff require timeouts, for example, and you
can't use ap_time_t for these because ap_time_t indicates an absolute time
rather than a relative time.
Dean
Re: time overhaul
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> oh hm, i see, maybe. actually i did put in a timeval <-> ap_time_t
> conversion initially because i thought i'd need it, but i found nothing
> required it... so i decided to take it out. i'm curious what needs it?
>
> is it intended for doing stuff like iol glue code? that makes sense.
> neat. sorry i didn't notice them.
It's okay, I'll commit mine now. :-)
>
> the other thing i'm thinking of doing is interval timers similar to
> NSPR's. this would be used for things such as the poll timeout interval.
> it would be a 64-bit microsecond-like thing as well.
How is this different from the ap_time_t that you already implemented?
What new functions would be added, what benefit does it give us that the
ap_time_t doesn't already provide?
Sorry, I don't see the need.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: time overhaul
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 9 Jan 2000, Dean Gaudet wrote:
> On Sun, 9 Jan 2000, Ryan Bloom wrote:
>
> > There are no ap_get_os_*time functions.
>
> this seems to defeat the purpose of a portability layer... i'm confused.
oh hm, i see, maybe. actually i did put in a timeval <-> ap_time_t
conversion initially because i thought i'd need it, but i found nothing
required it... so i decided to take it out. i'm curious what needs it?
is it intended for doing stuff like iol glue code? that makes sense.
neat. sorry i didn't notice them.
the other thing i'm thinking of doing is interval timers similar to
NSPR's. this would be used for things such as the poll timeout interval.
it would be a 64-bit microsecond-like thing as well.
Dean
Re: time overhaul
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 9 Jan 2000, Ryan Bloom wrote:
> ap_now doesn't return ap_status_t. Since gettimeofday does define some
> errno values, and I am pretty sure the windows get time functions willl
> have errno conditions, I don't like this. Plus, it goes against the APR
> design doc.
the return values from gettimeofday are meaningless, nobody ever tests
them -- and they only occur if you do something wrong, which we don't...
the current time always exists, if some kernel has trouble reporting it,
tough.
> There are no ap_get_os_*time functions.
this seems to defeat the purpose of a portability layer... i'm confused.
> The biggest difference to the core code, is that ap_now can't be used in
> calls to other functions, if anybody has a real problem with this, speak
> up now.
yup i've a problem with it. think of ap_now() as a global variable rather
than a function call please :)
Dean
Re: time overhaul
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I finally had a chance to look at the new time code. In general, I like
it, but I have a few problems.
ap_now doesn't return ap_status_t. Since gettimeofday does define some
errno values, and I am pretty sure the windows get time functions willl
have errno conditions, I don't like this. Plus, it goes against the APR
design doc.
There are no ap_get_os_*time functions.
I have a fix for both of these problems, but I have no way to test them
because of problems with modules.c. When I get the server compiling
again, I will commit my time changes.
The biggest difference to the core code, is that ap_now can't be used in
calls to other functions, if anybody has a real problem with this, speak
up now.
Ryan
> > ap_time_t is a scalar again, and can be used almost exactly like time_t
> > would be used -- except that it's 64-bits and in units of microseconds.
> >
> > ap_exploded_time_t is a structure containing all the human readable
> > fields.
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: time overhaul
Posted by David Reid <ab...@dial.pipex.com>.
+1
----- Original Message -----
From: "Dean Gaudet" <dg...@arctic.org>
To: <ne...@apache.org>
Sent: Saturday, January 08, 2000 9:00 PM
Subject: time overhaul
> the time thread got me worked up enough i started writing code. i'm about
> half way through overhauling the time representation in apr.
>
> ap_time_t is a scalar again, and can be used almost exactly like time_t
> would be used -- except that it's 64-bits and in units of microseconds.
>
> ap_exploded_time_t is a structure containing all the human readable
> fields.
>
> one nice thing is that the apache core code looks more like 1.3 this way
> than it did before... the portability layer is less obvious.
>
> when i check it in windows will be broken... but it shouldn't be hard to
> fix.
>
> Dean
>
Re: time overhaul
Posted by Greg Stein <gs...@lyra.org>.
+1
On Sat, 8 Jan 2000, Dean Gaudet wrote:
> the time thread got me worked up enough i started writing code. i'm about
> half way through overhauling the time representation in apr.
>
> ap_time_t is a scalar again, and can be used almost exactly like time_t
> would be used -- except that it's 64-bits and in units of microseconds.
>
> ap_exploded_time_t is a structure containing all the human readable
> fields.
>
> one nice thing is that the apache core code looks more like 1.3 this way
> than it did before... the portability layer is less obvious.
>
> when i check it in windows will be broken... but it shouldn't be hard to
> fix.
>
> Dean
>
--
Greg Stein, http://www.lyra.org/