You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by gr...@apache.org on 2003/07/03 16:31:21 UTC
Re: remaining issues prior to 1.0?
Brian Pane wrote:
>> What are the real issues stopping us from releasing APR 1.0?
> We still have the 64-bit divisions in the apr_time_t code.
It sure would be nice to make this one go away since it is most likely an API
change. But what are the chances we can come to a consensus on how to do it in
a reasonable time? Does someone have an objective summary of the proposals we
could look at, hopefully without starting a flame war?
Greg
Re: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 07:28 PM 9/1/2003, Justin Erenkrantz wrote:
>> Brian Pane wrote:
>>
>> Here's my attempt at summarizing all the proposals.
>> There was a lot of debate about the naming of the time
>> type--whether it was good or bad to give it a name so
>> similar to time_t, whether the type name should reflect
>> an implementation like binary microseconds, etc. For
>> simplicity, I'll just describe the implementations as
>> I remember them, independent of the naming issues.
>
>My take is that what we have now is fine for 1.0. Perfect? No. So be
>it. It works.
I agree here - I don't like the downsides of any of the alternatives (who does?)
but no longer prefer binary microseconds for the following reason...
...if you take a sample several times for delta time arithmetic you will get
rounding errors. Are these more significant than samples taken and summed
using the obvious rounding errors of 10(-6) decimal math? Probably not, but
users will be puzzled and frustrated by these sorts of discrepancies.
>Any changes to the time code can be in the next major release. This will
>give us enough time to appropriately discuss what should go in there.
1.0 is the major release.
>IIRC, there was also an explicit veto on any change to the time code
>because it could break source and/or binary compatibility. Therefore, if
>that veto still stands, we have to do any changes to the time code *after*
>1.0 not before. And, for lots of other reasons, I tend to agree to do it
>after 1.0.
I believe the veto was over changing this in the .9 development branch...
although this might be a developer's version, it is widely deployed today
and needs to be treated as a 'stable' version.
So for 1.0 itself, anything goes if we can come to concensus.
>Count me as post-1.0 for any time fixes. -- justin
Re: remaining issues prior to 1.0?
Posted by Stas Bekman <st...@stason.org>.
Cliff Woolley wrote:
> On Tue, 2 Sep 2003, Stas Bekman wrote:
>
>
>>3) there is no apr_file_tell
>>http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
>
>
> You don't need one. Just as there is an lseek() but no ltell(), you can
> do:
>
> apr_off_t offs = 0;
> apr_file_seek(fd, APR_CUR, &offs);
>
> at which point offs will have been updated to contain the current absolute
> position of the file pointer.
>
> The same thing applies to sysseek() in perl, by the way... there is no
> systell().
Thanks Cliff, wrowe has already suggested that back when I have asked about
it. I just thought that having a function for tell() will be useful, but I'm
fine without it as well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: remaining issues prior to 1.0?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 2 Sep 2003, Stas Bekman wrote:
> 3) there is no apr_file_tell
> http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
You don't need one. Just as there is an lseek() but no ltell(), you can
do:
apr_off_t offs = 0;
apr_file_seek(fd, APR_CUR, &offs);
at which point offs will have been updated to contain the current absolute
position of the file pointer.
The same thing applies to sysseek() in perl, by the way... there is no
systell().
--Cliff
Re: remaining issues prior to 1.0?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 12:04 AM 9/3/2003, Stas Bekman wrote:
>Justin Erenkrantz wrote:
>>--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman <st...@stason.org> wrote:
>>
>>>Other outstanding issues that IMHO can/should be fixed in 1.0.
>>>
>>>Configure issues:
>>>
>>>1) dealing with APR_HAS_LARGE_FILES on linux
>>>http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
>>>Currently it's just disabled, even when available.
>>>the whole thread is here:
>>>http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
>>
>>IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can step up and add the right configure logic. No API change is required here. We don't need to hold up 1.0 because no Linux developers care to fix it. (I don't have access to Linux boxes with working sendfile64, so I'm of zero help here.)
Might I humbly suggest that we *ignore* the issues with sendfile64 and simply
use largefiles, period? If they want apr_sendfile to behave, someone will step
up and fix it.
AFAICT, there are few 32-bit file size restrictions in the modern world.
Bill
Re: remaining issues prior to 1.0?
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Sep 02, 2003 at 10:04:52PM -0700, Stas Bekman wrote:
> Justin Erenkrantz wrote:
> >--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman
> ><st...@stason.org> wrote:
> >
> >>Other outstanding issues that IMHO can/should be fixed in 1.0.
> >>
> >>Configure issues:
> >>
> >>1) dealing with APR_HAS_LARGE_FILES on linux
> >>http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
> >>Currently it's just disabled, even when available.
> >>the whole thread is here:
> >>http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
> >
> >
> >IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can
> >step up and add the right configure logic. No API change is required
> >here. We don't need to hold up 1.0 because no Linux developers care to
> >fix it. (I don't have access to Linux boxes with working sendfile64, so
> >I'm of zero help here.)
>
> Isn't here anybody who understands the ./configure logic on linux?
If you just want a 64-bit apr_off_t on your 32-bit Linux you can already
just use
./configure CPPFLAGS="-D_FILE_OFFSET_BITS=64"
but changing the size of apr_off_t (and hence changing the library ABI)
is serious business - that's not a decision I'd want in the hands of a
configure check.
(you can get large file support without changing the size of apr_off_t,
but that's not simply a case of writing some configure gunk)
joe
Re: remaining issues prior to 1.0?
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman
> <st...@stason.org> wrote:
>
>> Other outstanding issues that IMHO can/should be fixed in 1.0.
>>
>> Configure issues:
>>
>> 1) dealing with APR_HAS_LARGE_FILES on linux
>> http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
>> Currently it's just disabled, even when available.
>> the whole thread is here:
>> http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
>
>
> IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can
> step up and add the right configure logic. No API change is required
> here. We don't need to hold up 1.0 because no Linux developers care to
> fix it. (I don't have access to Linux boxes with working sendfile64, so
> I'm of zero help here.)
Isn't here anybody who understands the ./configure logic on linux?
>> 1) apr_strfsize is limited to the availability of LARGEFILES support,
>> whereas it's advertised as a general purpose function and has nothing
>> to do
>> with the filesize. The thread that wasn't finished is here:
>> http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
>
>
> I'm not understanding why this is related to LARGEFILES at all? Do you
> mean that you'd want this to work with 64-bit integers regardless of
> apr_off_t's size? Don't see that as 'must-fix' before 1.0.
Yes. I suggested that the API name will be changes to reflect the reality.
>> 2) s/ap_ht_time/apr_date_format_http/g
>> http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
>> Bill says it's a good API change (move into apr):
>> http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
>
>
> According to the version rules, functions can be added at any time.
> Again, not a 1.0 showstopper.
Alright, but why not doing this simple change. It doesn't take longer than
running s/// and adjusting the header files.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: remaining issues prior to 1.0?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman <st...@stason.org>
wrote:
> Other outstanding issues that IMHO can/should be fixed in 1.0.
>
> Configure issues:
>
> 1) dealing with APR_HAS_LARGE_FILES on linux
> http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
> Currently it's just disabled, even when available.
> the whole thread is here:
> http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can step up
and add the right configure logic. No API change is required here. We don't
need to hold up 1.0 because no Linux developers care to fix it. (I don't have
access to Linux boxes with working sendfile64, so I'm of zero help here.)
> 1) apr_strfsize is limited to the availability of LARGEFILES support,
> whereas it's advertised as a general purpose function and has nothing to do
> with the filesize. The thread that wasn't finished is here:
> http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
I'm not understanding why this is related to LARGEFILES at all? Do you mean
that you'd want this to work with 64-bit integers regardless of apr_off_t's
size? Don't see that as 'must-fix' before 1.0.
> 2) s/ap_ht_time/apr_date_format_http/g
> http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
> Bill says it's a good API change (move into apr):
> http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
According to the version rules, functions can be added at any time. Again,
not a 1.0 showstopper.
> 3) there is no apr_file_tell
> http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
Cliff and I just talked about how you'd solve this in #apr. He's writing a
reply now. -- justin
Re: remaining issues prior to 1.0?
Posted by Stas Bekman <st...@stason.org>.
Other outstanding issues that IMHO can/should be fixed in 1.0.
Configure issues:
1) dealing with APR_HAS_LARGE_FILES on linux
http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
Currently it's just disabled, even when available.
the whole thread is here:
http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
API issues:
1) apr_strfsize is limited to the availability of LARGEFILES support, whereas
it's advertised as a general purpose function and has nothing to do with the
filesize. The thread that wasn't finished is here:
http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
The solution is simple: rename apr_strfsize to something that implies that it
works with file sizes only and provide a new general purpose function that
works with any size, unrelated to LARGEFILES.
2) s/ap_ht_time/apr_date_format_http/g
http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
Bill says it's a good API change (move into apr):
http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
3) there is no apr_file_tell
http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: remaining issues prior to 1.0?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
> Brian Pane wrote:
>
> Here's my attempt at summarizing all the proposals.
> There was a lot of debate about the naming of the time
> type--whether it was good or bad to give it a name so
> similar to time_t, whether the type name should reflect
> an implementation like binary microseconds, etc. For
> simplicity, I'll just describe the implementations as
> I remember them, independent of the naming issues.
My take is that what we have now is fine for 1.0. Perfect? No. So be
it. It works.
Any changes to the time code can be in the next major release. This will
give us enough time to appropriately discuss what should go in there.
IIRC, there was also an explicit veto on any change to the time code
because it could break source and/or binary compatibility. Therefore, if
that veto still stands, we have to do any changes to the time code *after*
1.0 not before. And, for lots of other reasons, I tend to agree to do it
after 1.0.
Count me as post-1.0 for any time fixes. -- justin
Re: remaining issues prior to 1.0?
Posted by Brian Pane <br...@cnet.com>.
On Thu, 2003-07-03 at 07:31, gregames@apache.org wrote:
> Brian Pane wrote:
>
> >> What are the real issues stopping us from releasing APR 1.0?
>
> > We still have the 64-bit divisions in the apr_time_t code.
>
> It sure would be nice to make this one go away since it is most likely an API
> change. But what are the chances we can come to a consensus on how to do it in
> a reasonable time? Does someone have an objective summary of the proposals we
> could look at, hopefully without starting a flame war?
Here's my attempt at summarizing all the proposals.
There was a lot of debate about the naming of the time
type--whether it was good or bad to give it a name so
similar to time_t, whether the type name should reflect
an implementation like binary microseconds, etc. For
simplicity, I'll just describe the implementations as
I remember them, independent of the naming issues.
1. Current design
How it works:
Time is stored in a 64-bit int as
(time_t * 1,000,000) + microseconds
Pros:
Time arithmetic is fast
Cons:
Extracting the seconds is slow
2. Binary microseconds
How it works:
Time is stored in a 64-bit int as
(time_t << 22) + microseconds
Pros:
Extracting the seconds is fast
Cons:
Extracting the microseconds is slow
3. Stop storing microseconds
How it works:
Time is stored as time_t, with no microseconds
Pros:
Works great for apps that only need seconds
No 64-bit multiplication/division performance
problems
Cons:
Doesn't work so well for apps that do need
microseconds
4. Struct
How it works:
Time is stored as a struct with separate fields
for seconds and microseconds
Pros:
Extracting seconds is fast
Cons:
Time arithmetic is slow
The pros and cons are tricky; the performance tradeoffs
that are ideal for one app may be unbearable for another.
The last time this topic came up, I ended up being in
favor of a variant of option 3:
http://marc.theaimsgroup.com/?m=102678180413988
Brian