You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@apache.org> on 2003/02/26 23:02:41 UTC
minor MMN bump for 2.0
I'd like to do a minor MMN bump in the 2.0 stable tree to account for the
apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. It's
not a huge deal unless you're a 3rd party module with a handler that needs all
the performance it can get, ala mod_specweb99. I'm not too concerned about the
2.1 tree; we can just piggyback on to one of the other recent MMN changes there.
Q. Shouldn't this really be a major bump?
A. Strictly speaking, yes. But that would cause more headaches than it would solve.
Can I get some votes on this, please?
Thanks,
Greg
Re: minor MMN bump for 2.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Ames wrote:
> Jeff Trawick wrote:
>
> > Regardless of a bump, it seems like the app is going to have to do
> >
> > #ifdef APR_ENABLE_SENDFILE
> > add in the flag
> > #endif
> >
> > unless they don't care what happens if they build it with 2.0.44.
>
>
> hey, that solves the whole thing, in both of the trees simultaneously!
> OK, we don't need a bump.
>
> I was thinking of:
>
> #if AP_MODULE_MAGIC_AT_LEAST(whatever)
> add in the flag
> #endif
well, that's probably the cool way but it is too late to work properly
(i.e., deal with 2.0.44)
Re: minor MMN bump for 2.0
Posted by Greg Ames <gr...@apache.org>.
Jeff Trawick wrote:
> Regardless of a bump, it seems like the app is going to have to do
>
> #ifdef APR_ENABLE_SENDFILE
> add in the flag
> #endif
>
> unless they don't care what happens if they build it with 2.0.44.
hey, that solves the whole thing, in both of the trees simultaneously! OK, we
don't need a bump.
I was thinking of:
#if AP_MODULE_MAGIC_AT_LEAST(whatever)
add in the flag
#endif
u da man!
Greg
Re: minor MMN bump for 2.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Ames wrote:
> I'd like to do a minor MMN bump in the 2.0 stable tree to account for
> the apr_file_open interface changing via the addition of
> APR_ENABLE_SENDFILE.
Regardless of a bump, it seems like the app is going to have to do
#ifdef APR_ENABLE_SENDFILE
add in the flag
#endif
unless they don't care what happens if they build it with 2.0.44.
Re: minor MMN bump for 2.0
Posted by Greg Ames <gr...@apache.org>.
William A. Rowe, Jr. wrote:
> At 05:07 PM 2/26/2003, Greg Ames wrote:
>
>
>>Sure. A handler which does its own apr_file_open looses the ability to use sendfile.
>
>
> Who cares?
Only people who value performance.
> That's an APR implementation-dependent detail that you (the module/app author) has minimal control over.
APR has nothing to do with how it works on Unix, other than being used as a
parameter passing mechanism between the default_handler and the
core_input_filter. Sure, APR comes into play on Win95, but I don't think there
are a whole lot of people seriously trying to maximize Apache performance on Win95.
Greg
Re: minor MMN bump for 2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:07 PM 2/26/2003, Greg Ames wrote:
>Sure. A handler which does its own apr_file_open looses the ability to use sendfile.
Who cares? That's an APR implementation-dependent detail that you
(the module/app author) has minimal control over.
Bill
Re: minor MMN bump for 2.0
Posted by Greg Ames <gr...@apache.org>.
Bill Stoddard wrote:
> Greg Ames wrote:
>
>> I'd like to do a minor MMN bump in the 2.0 stable tree to account for
>> the apr_file_open interface changing via the addition of
>> APR_ENABLE_SENDFILE. It's not a huge deal unless you're a 3rd party
>> module with a handler that needs all the performance it can get, ala
>> mod_specweb99. I'm not too concerned about the 2.1 tree; we can just
>> piggyback on to one of the other recent MMN changes there.
>>
>> Q. Shouldn't this really be a major bump?
>> A. Strictly speaking, yes. But that would cause more headaches than
>> it would solve.
>
>
> Why should this be a major bump? Is there any possible use of the API
> in 2.0.44 that would now be broken?
Sure. A handler which does its own apr_file_open looses the ability to use
sendfile.
Greg
Re: minor MMN bump for 2.0
Posted by Bill Stoddard <bi...@wstoddard.com>.
Greg Ames wrote:
> I'd like to do a minor MMN bump in the 2.0 stable tree to account for
> the apr_file_open interface changing via the addition of
> APR_ENABLE_SENDFILE. It's not a huge deal unless you're a 3rd party
> module with a handler that needs all the performance it can get, ala
> mod_specweb99. I'm not too concerned about the 2.1 tree; we can just
> piggyback on to one of the other recent MMN changes there.
>
> Q. Shouldn't this really be a major bump?
> A. Strictly speaking, yes. But that would cause more headaches than it
> would solve.
Why should this be a major bump? Is there any possible use of the API
in 2.0.44 that would now be broken?
Bill
Re: minor MMN bump for 2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:02 PM 2/26/2003, Greg Ames wrote:
>I'd like to do a minor MMN bump in the 2.0 stable tree to account for the apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. It's not a huge deal unless you're a 3rd party module with a handler that needs all the performance it can get, ala mod_specweb99. I'm not too concerned about the 2.1 tree; we can just piggyback on to one of the other recent MMN changes there.
>
>Q. Shouldn't this really be a major bump?
>A. Strictly speaking, yes. But that would cause more headaches than it would solve.
>
>Can I get some votes on this, please?
It's absolutely not a major bump - that is - modules with or without the flags
still *work*. We aren't breaking modules.
Now if you flipped the bit definition that would be a bigger problem - but we
already agreed that wouldn't happen - another flag would gain another new
bit.
In fact, I can't say that I see one reason to actually apply the bump. Running
a module with the flag, on apr built at any point won't "break" the module.
And APR isn't Apache. We shouldn't be bumping Apache, in any case, for
this change. This is a change to APR (and I regularly cross two different APR
and Apache versions for the best performance or the greatest reliability.)
So I'd say no, no bump. We are about to tag 0.9.2 (or is that 0.9.3) in the next
24 hours to create a candidate. That APR version 0.9.2 (-gold) will tell you that
your apr_file_open supports the new semantics.
The hassle is that we've been using 0.9.2-dev and there is no way to distinguish
the 'version' of apr between -dev and -gold. So I'm tempted to make this 0.9.3
and continue development on 0.9.3-dev till we are ready to call it 0.9.4.
But that discussion is off-topic here ... snipping that bit for the apr list
to continue the discussion there.
Bill