You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2003/01/08 16:15:56 UTC
Showstopper ... was: Tagged the tree
At 07:00 PM 1/7/2003, you wrote:
>Sander Striker wrote:
>
>>Hi,
>>
>>I tagged the tree with STRIKER_2_0_44_PRE2. The tag consists
>>of APACHE_2_0_BRANCH and apr/apr-util HEAD. If you feel that
>>something should not be in here, please let me know ASAP.
>
>What about the change in argument types for the APR queue
>and hash API? That's the one thing I know of that would
>break binary compatibility.
Beyond the queue and hash changes that break on all 64 bit platforms
(and should be reverted and deferred to APR 1.0), here are some other
interesting bits...
APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
- int length);
+ apr_size_t length);
won't pose a problem except on 64 bit LP and P platforms... on those
few (Win64/AIX/dunno which others) it should be postponed for the
APR 1.0 release (targeted by httpd-2.2.)
Just an observation reviewing the apr/includes/ changes... I don't like the
look of this code;
+#define apr_atomic_casptr(mem,with,cmp) (void*)atomic_cmpxchg((unsigned long *)(mem),(unsigned long)(cmp),(unsigned long)(with))
Very simply, this is a very easily broken macro... it is too easy to silently
pass the wrong pointer arg to apr_atomic_casptr and explode.
We need some type safety here, and this macro (I believe) destroys
all hope of that. It seems this needs to become a function. Macro to
function should be a safe change, since code compiled to an earlier
apr will continue to use this unsafe but otherwise usable macro.
For something completely different, once this is released, we are stuck
with the api...
#define APR_FILEPATH_ENCODING_UNKNOWN 0
#define APR_FILEPATH_ENCODING_LOCALE 1
#define APR_FILEPATH_ENCODING_UTF8 2
APR_DECLARE(apr_status_t) apr_filepath_encoding(int *style, apr_pool_t *p);
Why not drop the enum and use an apr_filepath_encoding that returns
an actual codepage name? Then the ambiguity of _LOCALE disappears.
Put another way, either APR_FILEPATH_ENCODING_LOCALE
with a locale of utf-8 or the APR_FILEPATH_ENCODING_UTF8 can
mean the same thing. This seems wrong. For that matter, it might
also be APR_FILEPATH_UNKNOWN if we didn't determine it.
Just asking for such things to be as clean as we can ask before we roll.
Finally, Brane has a patch that completes our apr-iconv work (even for
installing apr-iconv .so's when we aren't building httpd.) I'm vetting it and
should have it committed today so we can call it baked on win32.
To the dev@apr members, anyone feel like calling this 0.9.2 in conjunction
with httpd's next release and pushing on to 0.9.3-dev???
Bill
Re: Showstopper ... was: Tagged the tree
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:44 AM 1/9/2003, you wrote:
>William A. Rowe, Jr. wrote:
>
>>In that case... what about a trick (I believe) Ben Laurie taught us?
>>Using a typedef for clarity:
>>
>>typedef void*(*apr_atomic_casptr_fn_t)(unsigned long* mem, unsigned long cmp, unsigned long with);
>>
>>#define apr_atomic_casptr ((apr_atomic_casptr_fn_t)(atomic_cmpxchg))
>>
>>In this way, the arguments to apr_atomic_casptr will be evaluated in terms
>>of the apr_atomic_casptr_fn_t declaration.
>>
>>This presumes the arguments exactly match the atomic_cmpxchg function, with the exception of twos-compliment signedness.
>>
>>Make sense?
>
>I like the typedef approach, but shouldn't it be
>
>typedef void*(*apr_atomic_casptr_fn_t)(void** mem, const void *cmp, const void *with);
>
>since casptr operates on pointers rather than ints?
I wondered the same, I was just convoluting the existing macro...
Bill
Re: Showstopper ... was: Tagged the tree
Posted by Brian Pane <br...@cnet.com>.
William A. Rowe, Jr. wrote:
>In that case... what about a trick (I believe) Ben Laurie taught us?
>Using a typedef for clarity:
>
>typedef void*(*apr_atomic_casptr_fn_t)(unsigned long* mem, unsigned long cmp, unsigned long with);
>
>#define apr_atomic_casptr ((apr_atomic_casptr_fn_t)(atomic_cmpxchg))
>
>In this way, the arguments to apr_atomic_casptr will be evaluated in terms
>of the apr_atomic_casptr_fn_t declaration.
>
>This presumes the arguments exactly match the atomic_cmpxchg function,
>with the exception of twos-compliment signedness.
>
>Make sense?
>
I like the typedef approach, but shouldn't it be
typedef void*(*apr_atomic_casptr_fn_t)(void** mem, const void *cmp, const void *with);
since casptr operates on pointers rather than ints?
Brian
Re: Showstopper ... was: Tagged the tree
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
{Trimming this to @apr for this bit of discussion.}
At 10:16 AM 1/8/2003, Brian Pane wrote:
>On Wed, 2003-01-08 at 07:15, William A. Rowe, Jr. wrote:
>
>> Just an observation reviewing the apr/includes/ changes... I don't like the
>> look of this code;
>>
>> +#define apr_atomic_casptr(mem,with,cmp) (void*)atomic_cmpxchg((unsigned long *)(mem),(unsigned long)(cmp),(unsigned long)(with))
>>
>> Very simply, this is a very easily broken macro... it is too easy to silently
>> pass the wrong pointer arg to apr_atomic_casptr and explode.
>>
>> We need some type safety here, and this macro (I believe) destroys
>> all hope of that. It seems this needs to become a function. Macro to
>> function should be a safe change, since code compiled to an earlier
>> apr will continue to use this unsafe but otherwise usable macro.
>
>There's a good reason why the atomic CAS can't be a function.
>Its most common use is in spinlocks, where the probability of
>having to retry the CAS increases with every clock cycle you
>spend in the "if (cas failed) {retry;}" loop. Adding a function
>call around the CAS would double the length of the code path
>between the lookup of the old value and the compare-and-swap
>of the new value, which in turn doubles the probability that
>the CAS will fail and require a retry.
>
>As for type safety, keep in mind that the role of
>apr_atomic_casptr is to atomically swap any pointer to
>an object. If we were to turn it into a function, its first
>argument would have to be a void**.
In that case... what about a trick (I believe) Ben Laurie taught us?
Using a typedef for clarity:
typedef void*(*apr_atomic_casptr_fn_t)(unsigned long* mem, unsigned long cmp, unsigned long with);
#define apr_atomic_casptr ((apr_atomic_casptr_fn_t)(atomic_cmpxchg))
In this way, the arguments to apr_atomic_casptr will be evaluated in terms
of the apr_atomic_casptr_fn_t declaration.
This presumes the arguments exactly match the atomic_cmpxchg function,
with the exception of twos-compliment signedness.
Make sense?
Re: Showstopper ... was: Tagged the tree
Posted by Brian Pane <br...@cnet.com>.
On Wed, 2003-01-08 at 07:15, William A. Rowe, Jr. wrote:
> Just an observation reviewing the apr/includes/ changes... I don't like the
> look of this code;
>
> +#define apr_atomic_casptr(mem,with,cmp) (void*)atomic_cmpxchg((unsigned long *)(mem),(unsigned long)(cmp),(unsigned long)(with))
>
> Very simply, this is a very easily broken macro... it is too easy to silently
> pass the wrong pointer arg to apr_atomic_casptr and explode.
>
> We need some type safety here, and this macro (I believe) destroys
> all hope of that. It seems this needs to become a function. Macro to
> function should be a safe change, since code compiled to an earlier
> apr will continue to use this unsafe but otherwise usable macro.
There's a good reason why the atomic CAS can't be a function.
Its most common use is in spinlocks, where the probability of
having to retry the CAS increases with every clock cycle you
spend in the "if (cas failed) {retry;}" loop. Adding a function
call around the CAS would double the length of the code path
between the lookup of the old value and the compare-and-swap
of the new value, which in turn doubles the probability that
the CAS will fail and require a retry.
As for type safety, keep in mind that the role of
apr_atomic_casptr is to atomically swap any pointer to
an object. If we were to turn it into a function, its first
argument would have to be a void**.
> To the dev@apr members, anyone feel like calling this 0.9.2 in conjunction
> with httpd's next release and pushing on to 0.9.3-dev???
Okay with me.
Brian
Re: Showstopper ... was: Tagged the tree
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>For something completely different, once this is released, we are stuck
>with the api...
>
>#define APR_FILEPATH_ENCODING_UNKNOWN 0
>#define APR_FILEPATH_ENCODING_LOCALE 1
>#define APR_FILEPATH_ENCODING_UTF8 2
>APR_DECLARE(apr_status_t) apr_filepath_encoding(int *style, apr_pool_t *p);
>
>Why not drop the enum and use an apr_filepath_encoding that returns
>an actual codepage name? Then the ambiguity of _LOCALE disappears.
>
>Put another way, either APR_FILEPATH_ENCODING_LOCALE
>with a locale of utf-8 or the APR_FILEPATH_ENCODING_UTF8 can
>mean the same thing. This seems wrong.
>
It's not. you get _UTF8 only when _UTF8 is _not_ the same as _LOCALE
> For that matter, it might
>also be APR_FILEPATH_UNKNOWN if we didn't determine it.
>
I don't really expect any implementation fo apr_filepath_encoding to
return _UNKNOWN; it's there for completeness. If there is such an
implementation, it probably also can't implement apr_os_locale_encoding
and falls back on apr_os_default_encoding -- meaning "I don't know."
>Just asking for such things to be as clean as we can ask before we roll.
>
>
I spent much time and though (and discussion) wondering about this same
issue. I decided to do it this way because we already have functions
that return the name of the locale encoding, which apps can use if
necessary. An application really only has to know the difference between
_LOCALE and _UTF8, and convert accordingly; it doesn't necessarily have
to know the actual name of the encoding, so calling
apr_os_locale_encoding from apr_filepath_encoding is just a waste of
cycles, and so is "strcmp(foo,"UTF-8")" instead of
(foo==APR_FILEPATH_ENCODING_UTF8).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Showstopper ... was: Tagged the tree
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 09, 2003 at 05:02:10PM -0600, William A. Rowe, Jr. wrote:
> At 03:43 PM 1/9/2003, Greg Stein wrote:
>...
> >No. *YOU* have tried to stick to it. The versioning rules don't support this
> >position. APR hasn't gone final, so it isn't bound to any contract.
>
> I am not the only one who helped with this effort. Even if we aren't bound,
> there's no reason to be impolite when we can avoid it.
True, and I think we have been keeping that in mind. But something like the
error codes was just plain necessary. We were using a miserly 500 value
increment between the groups. Karl expanded that to 50000.
And it is that "necessary" that I'm talking about. httpd cannot hold us back
from what is Good for APR(UTIL).
> >> >IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, call that API 1.0. Apply relevant fixes as needed (bumping versions based on the version rules - i.e. filepath_encoding bumps the minor). Then, start on APR 2.0 with removal of deprecated functions and we can change signatures as we like. -- justin
> >
> >Agreed. I'd state that we make the 0.9.x branch for httpd, and change the
> >HEAD to be 0.10.x. When we feel cozy, then we can pop to 1.0.
>
> I guess I'm confused... what does 0.10.x gain us, when we are free to introduce
> new APIs over the next generation?
>
> In other words, what is wrong with blessing the current code as APR 1.0,
> less all deprecated facilities?
Because I'm not sure that people feel it is 1.0 quality. Are we ready to
tell the universe that APR is "API stable, and ready for all your needs" ?
It just doesn't feel that solid.
Maybe I'm being a bit too conservative. I *do* see your point about just
saying "yup. this is a 1.0 with all that entails. it is solid and robust,
but it is the *first* release."
> If there are such issues right now, they belong in STATUS. It's been a little
> while since I visited that doc, so I'm wandering over there this evening.
I can't pinpoint anything, so I don't know what to put there :-)
I do think we need some more work on the apr/apr-util/httpd build
interaction. I wouldn't hold up a 0.9.2 or 0.10.0 release on that, but I
think it would be good to have that nailed down a bit better for 1.0.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Showstopper ... was: Tagged the tree
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:43 PM 1/9/2003, Greg Stein wrote:
>On Thu, Jan 09, 2003 at 02:26:50PM -0600, William A. Rowe, Jr. wrote:
>> We are waiting on only one thing for APR 1.0, the full set of versioning
>> API functions. I don't know where this stands, and I know Greg was
>> full of ideas/designs. I'd like to see some feedback on this.
>
>The versioning mechanisms, functions, etc are all fully coded. They were
>that way before I spun up the 0.9.0 release. The versioning document
>outlines all of the human background for using that.
Coolness.
>> >>Committing the change was the breakage. It violated -our-
>> >>versioning rules. With the holidays, many eyes had been distracted
>> >>elsewhere, so now we are just playing catch-up to catch invalid
>> >>commits.
>> >
>> >No, it wasn't. We've broken the API lots of times before in the 0.9.x series. You just want to enforce backwards-compatibility on APR when it isn't ready because a project that uses APR requires backwards-compatibility. Part of me says, "Tough." httpd made a poor decision relying upon a library that wasn't 1.0 with fixed version rules.
>>
>> Quit it... we've been binary compatible for many successive httpd releases.
>
>Happenstance. APR(UTIL) is free to change its API. You're missing that
>point.
And I suggest that *because* we aren't prohibited isn't a reason to just
introduce gratuitous breakage.
>> We've proven the 90/10 rule that few changes need to break binary compat.
>> And we've tried to stick to it. These changes we are discussing are minor,
>> gratuitous, and introduce breakage just for the sake of breaking compatibility.
>
>No. *YOU* have tried to stick to it. The versioning rules don't support this
>position. APR hasn't gone final, so it isn't bound to any contract.
I am not the only one who helped with this effort. Even if we aren't bound,
there's no reason to be impolite when we can avoid it.
>> >IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, call that API 1.0. Apply relevant fixes as needed (bumping versions based on the version rules - i.e. filepath_encoding bumps the minor). Then, start on APR 2.0 with removal of deprecated functions and we can change signatures as we like. -- justin
>
>Agreed. I'd state that we make the 0.9.x branch for httpd, and change the
>HEAD to be 0.10.x. When we feel cozy, then we can pop to 1.0.
I guess I'm confused... what does 0.10.x gain us, when we are free to introduce
new APIs over the next generation?
In other words, what is wrong with blessing the current code as APR 1.0,
less all deprecated facilities?
If there are such issues right now, they belong in STATUS. It's been a little
while since I visited that doc, so I'm wandering over there this evening.
Bill
Re: Showstopper ... was: Tagged the tree
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:43 PM 1/9/2003, Greg Stein wrote:
>On Thu, Jan 09, 2003 at 02:26:50PM -0600, William A. Rowe, Jr. wrote:
>
>> Because 0.9, for a while, will inherit the renaming
>> going on for 1.0, any 1.0 code that doesn't use new features can still be
>> compiled (but won't be binary compatible) with 0.9 and httpd-2.0.
>
>I don't follow that. (prolly doesn't matter tho, based on other parts of my
>email)
I think this will make it clearer...
>> We are close, I agree. But there is no reason for all of these deprecated
>> 0.9 APIs to persist into 1.0, and there is no reason for httpd-2.0 to move
>> onwards to 1.0
>
>Agreed.
>
>> (although you must be able to compile httpd-2.0 in either APR 0.9 or 1.0,
>> the two builds are just not binary compatible.)
>
>Nope. That jump in the major version implies an ability to break the source
>compatibility. We cannot release APR with a broken API, thus the need to
>allow changes to it.
The point is that we are sort of unlikely to change any APIs in such as way
as httpd-2.0 *itself* won't compile against APR 1.0.
We *could* do so, but I just don't see that as a *likelihood*.
So it's probably correct that if we provide any 'renamed' functions on the
APR 0.9 branch (keeping the deprecated wrappers for 3rd party authors)
and use the 'new' function names from 1.0/0.9, then it probably will build.
My point is that just 'because' it can, doesn't mean that we are free to
release httpd-2.0 binaries built on APR 1.0. Because releasing such
a binary would break compatibility with the 3rd party module community.
Bill
Re: Showstopper ... was: Tagged the tree
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 09, 2003 at 02:26:50PM -0600, William A. Rowe, Jr. wrote:
> We are waiting on only one thing for APR 1.0, the full set of versioning
> API functions. I don't know where this stands, and I know Greg was
> full of ideas/designs. I'd like to see some feedback on this.
The versioning mechanisms, functions, etc are all fully coded. They were
that way before I spun up the 0.9.0 release. The versioning document
outlines all of the human background for using that.
>...
> Yes, httpd-2.0 is/will be forever keyed to 0.9.
Right. So we need to create a branch in APR that httpd can use for
maintenance. APR is going to advance on its own schedule, so httpd needs to
pin to a specific revision and just go with that.
> We need to clear out all of
> the early design cruft going forward. Quickly, so that authors adopting the
> httpd-2.1 model have the right declarations and none of the historic and now
> dead macros or stubs.
We get to clear it out at any point leading up to 1.0. That is exactly what
the rules state. We aren't doing it out of "niceness" for httpd. But before
a product is 1.0, it is free to do as it likes.
> Because 0.9, for a while, will inherit the renaming
> going on for 1.0, any 1.0 code that doesn't use new features can still be
> compiled (but won't be binary compatible) with 0.9 and httpd-2.0.
I don't follow that. (prolly doesn't matter tho, based on other parts of my
email)
> >>Committing the change was the breakage. It violated -our-
> >>versioning rules. With the holidays, many eyes had been distracted
> >>elsewhere, so now we are just playing catch-up to catch invalid
> >>commits.
> >
> >No, it wasn't. We've broken the API lots of times before in the 0.9.x series. You just want to enforce backwards-compatibility on APR when it isn't ready because a project that uses APR requires backwards-compatibility. Part of me says, "Tough." httpd made a poor decision relying upon a library that wasn't 1.0 with fixed version rules.
>
> Quit it... we've been binary compatible for many successive httpd releases.
Happenstance. APR(UTIL) is free to change its API. You're missing that
point.
> In fact, the last binary breakage was the 'widening' of the error number ranges,
> and the poll change, which in hindsite I would have vetoed for later release
> in the APR 1.0. No matter, that's done and we're moving forwards.
>
> We've proven the 90/10 rule that few changes need to break binary compat.
> And we've tried to stick to it. These changes we are discussing are minor,
> gratuitous, and introduce breakage just for the sake of breaking compatibility.
No. *YOU* have tried to stick to it. The versioning rules don't support this
position. APR hasn't gone final, so it isn't bound to any contract.
> >IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, call that API 1.0. Apply relevant fixes as needed (bumping versions based on the version rules - i.e. filepath_encoding bumps the minor). Then, start on APR 2.0 with removal of deprecated functions and we can change signatures as we like. -- justin
Agreed. I'd state that we make the 0.9.x branch for httpd, and change the
HEAD to be 0.10.x. When we feel cozy, then we can pop to 1.0.
(altho, I would also suggest we spin the minor number for releases, rather
than the patch level; i.e. release 0.10.0, then 0.11.0, then 0.12.0; if we
need a quick patch, we can do 0.11.1 or somesuch)
> No, we agreed a long time ago that versioning must be complete and immutable
> before we call this APR 1.0.
The versioning system is, yes. The APIs are sufficient, along with the rules
to support them. I'm a bit leery of allowing new functions in minor releases
mixed in with how we construct our library names, but I think we'll see how
that pans out; we can always change how we name libraries.
> Versioning APIs and macros shouldn't be changed
> between 1.0, 2.0, 3.0 and so on, so let's take the time and get it right.
Nobody has suggested any chagne to the APIs or macros.
> Branch
> APR_0_9_BRANCH for maintenance alone,
For maintenance for httpd, yes.
> and move on with the final '1.0' rollout.
We'd move to 0.10.0-dev and march towards 1.0, yes.
> We are close, I agree. But there is no reason for all of these deprecated
> 0.9 APIs to persist into 1.0, and there is no reason for httpd-2.0 to move onwards
> to 1.0
Agreed.
> (although you must be able to compile httpd-2.0 in either APR 0.9 or 1.0,
> the two builds are just not binary compatible.)
Nope. That jump in the major version implies an ability to break the source
compatibility. We cannot release APR with a broken API, thus the need to
allow changes to it.
> Because httpd-2.0 is trying to remain binary compatible, it needs to stay back
> on APR 0.9 for official binary releases.
Yup. I'm +1 on going "back" and create a branch for 0.9.x and key httpd to
that. People can backport changes to that branch.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Showstopper ... was: Tagged the tree
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
We are waiting on only one thing for APR 1.0, the full set of versioning
API functions. I don't know where this stands, and I know Greg was
full of ideas/designs. I'd like to see some feedback on this.
>That can't work. httpd 2.0 needs the ability to work against a stable release of APR. Hence, the APR 1.0 vs. 2.0 breakout.
You are assuming that httpd 2.0 will be as long-lived a version as httpd 1.3,
but that isn't going to happen.
httpd 1.3 must be a long-lived version, because of the major overhaul involved
in creating httpd 2.0. httpd 2.2 should be a rapidly adopted version because
deployed servers and 3rd party modules won't be nearly as hard to migrate
as the 1.3 to 2.0 migration. Some oddball platforms still can't build httpd-2.0
while they can build 1.3, with the introduction of libtool. And their favorite
modules still might not have an httpd-2.0 port, partly due to the 'moving target'
of httpd-2.0 development.
Yes, httpd-2.0 is/will be forever keyed to 0.9. We need to clear out all of
the early design cruft going forward. Quickly, so that authors adopting the
httpd-2.1 model have the right declarations and none of the historic and now
dead macros or stubs. Because 0.9, for a while, will inherit the renaming
going on for 1.0, any 1.0 code that doesn't use new features can still be
compiled (but won't be binary compatible) with 0.9 and httpd-2.0.
>>Committing the change was the breakage. It violated -our-
>>versioning rules. With the holidays, many eyes had been distracted
>>elsewhere, so now we are just playing catch-up to catch invalid
>>commits.
>
>No, it wasn't. We've broken the API lots of times before in the 0.9.x series. You just want to enforce backwards-compatibility on APR when it isn't ready because a project that uses APR requires backwards-compatibility. Part of me says, "Tough." httpd made a poor decision relying upon a library that wasn't 1.0 with fixed version rules.
Quit it... we've been binary compatible for many successive httpd releases.
In fact, the last binary breakage was the 'widening' of the error number ranges,
and the poll change, which in hindsite I would have vetoed for later release
in the APR 1.0. No matter, that's done and we're moving forwards.
We've proven the 90/10 rule that few changes need to break binary compat.
And we've tried to stick to it. These changes we are discussing are minor,
gratuitous, and introduce breakage just for the sake of breaking compatibility.
>IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, call that API 1.0. Apply relevant fixes as needed (bumping versions based on the version rules - i.e. filepath_encoding bumps the minor). Then, start on APR 2.0 with removal of deprecated functions and we can change signatures as we like. -- justin
No, we agreed a long time ago that versioning must be complete and immutable
before we call this APR 1.0. Versioning APIs and macros shouldn't be changed
between 1.0, 2.0, 3.0 and so on, so let's take the time and get it right. Branch
APR_0_9_BRANCH for maintenance alone, and move on with the final '1.0'
rollout. We are close, I agree. But there is no reason for all of these deprecated
0.9 APIs to persist into 1.0, and there is no reason for httpd-2.0 to move onwards
to 1.0 (although you must be able to compile httpd-2.0 in either APR 0.9 or 1.0,
the two builds are just not binary compatible.)
Because httpd-2.0 is trying to remain binary compatible, it needs to stay back
on APR 0.9 for official binary releases.
Bill
Re: Showstopper ... was: Tagged the tree
Posted by David Reid <dr...@jetnet.co.uk>.
> > --On Thursday, January 9, 2003 1:07 PM -0600 "William A. Rowe, Jr."
> > <wr...@rowe-clan.net> wrote:
> >
> > > No, as I original proposed, httpd-2.2 will target APR 1.0. In
> > > fact, httpd-2.2 won't even be released until APR hits that magic
> > > number. All the old cruft deprecated over the development history
> > > of APR 0.9.x will evaporate.
> >
> > That can't work. httpd 2.0 needs the ability to work against a stable
> > release of APR. Hence, the APR 1.0 vs. 2.0 breakout.
>
> Whether or not httpd 2.0 needs to work with something called APR 1.0
> is a matter of opinion, and I guess it is time to start some votes in
> httpd-2.0 STATUS.
>
> I think there will be some agreement among httpd-ers on creating an
> APR branch from 2.0.43 and using that branch for httpd 2.0. Whether
> or not the APR-ers want to call such a branch APR 1.0 is something to
> be dealt with by a somewhat different set of people.
Seems reasonable...
david
Re: Showstopper ... was: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@apache.org> writes:
> --On Thursday, January 9, 2003 1:07 PM -0600 "William A. Rowe, Jr."
> <wr...@rowe-clan.net> wrote:
>
> > No, as I original proposed, httpd-2.2 will target APR 1.0. In
> > fact, httpd-2.2 won't even be released until APR hits that magic
> > number. All the old cruft deprecated over the development history
> > of APR 0.9.x will evaporate.
>
> That can't work. httpd 2.0 needs the ability to work against a stable
> release of APR. Hence, the APR 1.0 vs. 2.0 breakout.
Whether or not httpd 2.0 needs to work with something called APR 1.0
is a matter of opinion, and I guess it is time to start some votes in
httpd-2.0 STATUS.
I think there will be some agreement among httpd-ers on creating an
APR branch from 2.0.43 and using that branch for httpd 2.0. Whether
or not the APR-ers want to call such a branch APR 1.0 is something to
be dealt with by a somewhat different set of people.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: Showstopper ... was: Tagged the tree
Posted by Bill Stoddard <bi...@wstoddard.com>.
> IMHO, the proper thing to do is to branch off APR from where 2.0.43
> went off, call that API 1.0. Apply relevant fixes as needed (bumping
> versions based on the version rules - i.e. filepath_encoding bumps
> the minor). Then, start on APR 2.0 with removal of deprecated
> functions and we can change signatures as we like. -- justin
+1. httpd 2.2 does not go out until apr 2.0 is stable.
Bill
Re: Showstopper ... was: Tagged the tree
Posted by Justin Erenkrantz <je...@apache.org>.
--On Thursday, January 9, 2003 1:07 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> No... as Jeff reminded us, APR 0.9.x must retain backward-compat.
No, our version rules were never meant to be enforced prior to 1.0.
(The versioning rules are perfectly clear on this.) People only want
backwards-compatibility because of httpd 2.0. The cart is dragging
the horse here.
> No, as I original proposed, httpd-2.2 will target APR 1.0. In
> fact, httpd-2.2 won't even be released until APR hits that magic
> number. All the old cruft deprecated over the development history
> of APR 0.9.x will evaporate.
That can't work. httpd 2.0 needs the ability to work against a
stable release of APR. Hence, the APR 1.0 vs. 2.0 breakout.
> Committing the change was the breakage. It violated -our-
> versioning rules. With the holidays, many eyes had been distracted
> elsewhere, so now we are just playing catch-up to catch invalid
> commits.
No, it wasn't. We've broken the API lots of times before in the
0.9.x series. You just want to enforce backwards-compatibility on
APR when it isn't ready because a project that uses APR requires
backwards-compatibility. Part of me says, "Tough." httpd made a
poor decision relying upon a library that wasn't 1.0 with fixed
version rules.
IMHO, the proper thing to do is to branch off APR from where 2.0.43
went off, call that API 1.0. Apply relevant fixes as needed (bumping
versions based on the version rules - i.e. filepath_encoding bumps
the minor). Then, start on APR 2.0 with removal of deprecated
functions and we can change signatures as we like. -- justin
Re: Showstopper ... was: Tagged the tree
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:28 PM 1/9/2003, Justin Erenkrantz wrote:
>--On Thursday, January 9, 2003 11:17 AM -0500 Jeff Trawick <tr...@attglobal.net> wrote:
>
>>yuck...
>>
>>move Sander's tag back or back out the change to APR until the
>>window just prior to 1.0?
>
>As has been pointed out, APR 1.0 must maintain backwards-compatibility with what we're using right now for httpd.
No... as Jeff reminded us, APR 0.9.x must retain backward-compat.
>In essence, we already froze the APR API the second httpd-2.0 branched off since httpd guaranteed binary compatibility forever (which includes APR). Perhaps we should start considering moving to APR 2.0 *very* soon.
No, as I original proposed, httpd-2.2 will target APR 1.0. In fact, httpd-2.2
won't even be released until APR hits that magic number. All the old cruft
deprecated over the development history of APR 0.9.x will evaporate.
And I'd even go so far as suggest that the httpd project will be encouraged
to choose the most recent, stable APR tag for each of its releases as the
APR 1.x evolves.
>Reverting the change seems like we have an extremely broken versioning process somewhere. I hate that httpd is affecting APR. -- justin
Committing the change was the breakage. It violated -our- versioning rules.
With the holidays, many eyes had been distracted elsewhere, so now we
are just playing catch-up to catch invalid commits.
I *like* these changes, but they don't belong in APR 0.9.x.
Just mark them deferred. Better yet, we started using the syntax;
#ifdef APR_ENABLE_FOR_1_0 /* not yet */
newdecl
#else
currentdecl
#endif
Which would at least document what we are going to do to people
when APR evolves to 1.0.
Bill
Re: Showstopper ... was: Tagged the tree
Posted by Justin Erenkrantz <je...@apache.org>.
--On Thursday, January 9, 2003 2:20 PM -0500 Jeff Trawick
<tr...@attglobal.net> wrote:
> Silly me. I thought that Apache 2.0 would use APR 0.9.x and Apache
> >= 2.1 would switch to APR 1.0.
There was a thread a few weeks ago where we realized that this would
be impracticable. If httpd 2.0 only used APR 0.9.1-dev (say), then a
lot of applications want to be compatible with httpd 2.0 (say
modules). Therefore, they want a stable APR release that works with
httpd 2.0 above all else. If we abandon APR 0.9.1 and move to 1.0,
then we're abandoning them.
Therefore, what we have right now must be APR 1.0. Any changes going
forward *must* be APR 2.0 only. We can't drop deprecated functions
in APR 1.0 nor can we alter function signatures in APR 1.0 from what
we have right now.
We've already started 2.0, but we just haven't admitted it. -- justin
Re: Showstopper ... was: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@apache.org> writes:
> --On Thursday, January 9, 2003 11:17 AM -0500 Jeff Trawick
> <tr...@attglobal.net> wrote:
>
> > yuck...
> >
> > move Sander's tag back or back out the change to APR until the
> > window just prior to 1.0?
>
> As has been pointed out, APR 1.0 must maintain backwards-compatibility
> with what we're using right now for httpd. In essence, we already
> froze the APR API the second httpd-2.0 branched off since httpd
> guaranteed binary compatibility forever (which includes APR). Perhaps
> we should start considering moving to APR 2.0 *very* soon.
Silly me. I thought that Apache 2.0 would use APR 0.9.x and Apache >=
2.1 would switch to APR 1.0.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Showstopper ... was: Tagged the tree
Posted by Justin Erenkrantz <je...@apache.org>.
--On Thursday, January 9, 2003 11:17 AM -0500 Jeff Trawick
<tr...@attglobal.net> wrote:
> yuck...
>
> move Sander's tag back or back out the change to APR until the
> window just prior to 1.0?
As has been pointed out, APR 1.0 must maintain
backwards-compatibility with what we're using right now for httpd.
In essence, we already froze the APR API the second httpd-2.0
branched off since httpd guaranteed binary compatibility forever
(which includes APR). Perhaps we should start considering moving to
APR 2.0 *very* soon.
Reverting the change seems like we have an extremely broken
versioning process somewhere. I hate that httpd is affecting APR.
-- justin
Re: Showstopper ... was: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> At 07:00 PM 1/7/2003, you wrote:
> >Sander Striker wrote:
> >
> >>Hi,
> >>
> >>I tagged the tree with STRIKER_2_0_44_PRE2. The tag consists
> >>of APACHE_2_0_BRANCH and apr/apr-util HEAD. If you feel that
> >>something should not be in here, please let me know ASAP.
> >
> >What about the change in argument types for the APR queue
> >and hash API? That's the one thing I know of that would
> >break binary compatibility.
yuck...
move Sander's tag back or back out the change to APR until the window
just prior to 1.0?
> Beyond the queue and hash changes that break on all 64 bit platforms
> (and should be reverted and deferred to APR 1.0), here are some other
> interesting bits...
>
> APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
> - int length);
> + apr_size_t length);
>
> won't pose a problem except on 64 bit LP and P platforms... on those
> few (Win64/AIX/dunno which others) it should be postponed for the
> APR 1.0 release (targeted by httpd-2.2.)
same comment as above
> For something completely different, once this is released, we are stuck
> with the api...
through the 0.9.x series
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Showstopper ... was: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> At 07:00 PM 1/7/2003, you wrote:
> >Sander Striker wrote:
> >
> >>Hi,
> >>
> >>I tagged the tree with STRIKER_2_0_44_PRE2. The tag consists
> >>of APACHE_2_0_BRANCH and apr/apr-util HEAD. If you feel that
> >>something should not be in here, please let me know ASAP.
> >
> >What about the change in argument types for the APR queue
> >and hash API? That's the one thing I know of that would
> >break binary compatibility.
yuck...
move Sander's tag back or back out the change to APR until the window
just prior to 1.0?
> Beyond the queue and hash changes that break on all 64 bit platforms
> (and should be reverted and deferred to APR 1.0), here are some other
> interesting bits...
>
> APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
> - int length);
> + apr_size_t length);
>
> won't pose a problem except on 64 bit LP and P platforms... on those
> few (Win64/AIX/dunno which others) it should be postponed for the
> APR 1.0 release (targeted by httpd-2.2.)
same comment as above
> For something completely different, once this is released, we are stuck
> with the api...
through the 0.9.x series
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Showstopper ... was: Tagged the tree
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>For something completely different, once this is released, we are stuck
>with the api...
>
>#define APR_FILEPATH_ENCODING_UNKNOWN 0
>#define APR_FILEPATH_ENCODING_LOCALE 1
>#define APR_FILEPATH_ENCODING_UTF8 2
>APR_DECLARE(apr_status_t) apr_filepath_encoding(int *style, apr_pool_t *p);
>
>Why not drop the enum and use an apr_filepath_encoding that returns
>an actual codepage name? Then the ambiguity of _LOCALE disappears.
>
>Put another way, either APR_FILEPATH_ENCODING_LOCALE
>with a locale of utf-8 or the APR_FILEPATH_ENCODING_UTF8 can
>mean the same thing. This seems wrong.
>
It's not. you get _UTF8 only when _UTF8 is _not_ the same as _LOCALE
> For that matter, it might
>also be APR_FILEPATH_UNKNOWN if we didn't determine it.
>
I don't really expect any implementation fo apr_filepath_encoding to
return _UNKNOWN; it's there for completeness. If there is such an
implementation, it probably also can't implement apr_os_locale_encoding
and falls back on apr_os_default_encoding -- meaning "I don't know."
>Just asking for such things to be as clean as we can ask before we roll.
>
>
I spent much time and though (and discussion) wondering about this same
issue. I decided to do it this way because we already have functions
that return the name of the locale encoding, which apps can use if
necessary. An application really only has to know the difference between
_LOCALE and _UTF8, and convert accordingly; it doesn't necessarily have
to know the actual name of the encoding, so calling
apr_os_locale_encoding from apr_filepath_encoding is just a waste of
cycles, and so is "strcmp(foo,"UTF-8")" instead of
(foo==APR_FILEPATH_ENCODING_UTF8).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Showstopper ... was: Tagged the tree
Posted by Brian Pane <br...@cnet.com>.
On Wed, 2003-01-08 at 07:15, William A. Rowe, Jr. wrote:
> Just an observation reviewing the apr/includes/ changes... I don't like the
> look of this code;
>
> +#define apr_atomic_casptr(mem,with,cmp) (void*)atomic_cmpxchg((unsigned long *)(mem),(unsigned long)(cmp),(unsigned long)(with))
>
> Very simply, this is a very easily broken macro... it is too easy to silently
> pass the wrong pointer arg to apr_atomic_casptr and explode.
>
> We need some type safety here, and this macro (I believe) destroys
> all hope of that. It seems this needs to become a function. Macro to
> function should be a safe change, since code compiled to an earlier
> apr will continue to use this unsafe but otherwise usable macro.
There's a good reason why the atomic CAS can't be a function.
Its most common use is in spinlocks, where the probability of
having to retry the CAS increases with every clock cycle you
spend in the "if (cas failed) {retry;}" loop. Adding a function
call around the CAS would double the length of the code path
between the lookup of the old value and the compare-and-swap
of the new value, which in turn doubles the probability that
the CAS will fail and require a retry.
As for type safety, keep in mind that the role of
apr_atomic_casptr is to atomically swap any pointer to
an object. If we were to turn it into a function, its first
argument would have to be a void**.
> To the dev@apr members, anyone feel like calling this 0.9.2 in conjunction
> with httpd's next release and pushing on to 0.9.3-dev???
Okay with me.
Brian