You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/04/01 04:22:36 UTC
Re: 2.0.34 up-to-date wrt cvs HEAD
At 03:01 PM 3/31/2002, Cliff wrote:
>The error you're getting is "pointers to functions with different
>attributes". My only humble guess is that it's a problem with
>apr_bucket_free() being APU_DECLARE'd and the parameter to
>apr_bucket_heap_create/make() not specifying that. Does that sound like a
>logical hypothesis? If it's not that, I'm running out of ideas. If it is
>that, I still don't know how to fix it. :)
With _NONSTD, which tells msvc that the function is to be declared _cdecl
(e.g. the usual void foo(void arg) declaration) as opposed to _stdcall, which
uses pascal - callee pops the args on return - convention.
The patch is applied and the tag adjusted appropriately. Thanks for catching
this one, Jerry, and good call Cliff!
Bill
2.0-GA? Re: 2.0.34 up-to-date wrt cvs HEAD
Posted by Brian Pane <bp...@pacbell.net>.
William A. Rowe, Jr. wrote:
...
> And once it survives the daedalus stress test we should be all set
> for a pretty thorough beta. Things finally look quite stable,
> development
> wise, and we have a few folks interested in exploring those 'deferred for
> 2.1/3.0' sorts of features. Not that 2.0 bugfixing should come to some
> abrupt halt - only that 2.0 should become a stable tree, and new growth
> should start occuring on 2.1/3.0 type trees, depending on how radical
> the surgery that's required.
Based on the apparent good condition of 2.0.34, I'm
starting to think of 2.0.35 as a likely GA candidate.
The things I know of that should be in a GA release are:
* Cliff's bucket allocator speedup patch
* Any additional perchild fixes that might be needed
* A fix for the mod_include segfault problem that Paul
Reder is investigating
* And any miscellaneous bugfixes that happen between
now and then.
Am I missing anything? Based on that list, I estimate
that we could be ready to tag 2.0.35 in a week or two,
assuming no major problems emerge in .34.
--Brian
Re: 2.0.34 up-to-date wrt cvs HEAD
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:39 PM 3/31/2002, you wrote:
>On Sun, Mar 31, 2002 at 09:09:52PM -0600, William A. Rowe, Jr. wrote:
> > I don't expect us to 'measure' 2.0.34 against perchild, only worker
> > and threaded mpms [and win32, netware specific mpms.] As long as
> > the changes to server/mpm/perchild are finished when we are ready
> > to roll (probably tomorrow evening, giving folks a chance to test the
> > APACHE_2_0_34 tag and uncover any issues, as Jerry Baker has
> > already done) then I'm fine with including those changes.
>
>Do we plan to test out 2.0.34 on daedalus before rolling? -- justin
I'm not concerned about the 3 day test - only for declaring this a 'beta'.
Even if it's alpha quality - I'd like to know that APACHE_2_0_34 builds
and runs under as many configs as possible over the next day so we
can roll tarballs tomorrow night.
And once it survives the daedalus stress test we should be all set
for a pretty thorough beta. Things finally look quite stable, development
wise, and we have a few folks interested in exploring those 'deferred for
2.1/3.0' sorts of features. Not that 2.0 bugfixing should come to some
abrupt halt - only that 2.0 should become a stable tree, and new growth
should start occuring on 2.1/3.0 type trees, depending on how radical
the surgery that's required.
Bill
Re: 2.0.34 up-to-date wrt cvs HEAD
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Mar 31, 2002 at 09:09:52PM -0600, William A. Rowe, Jr. wrote:
> I don't expect us to 'measure' 2.0.34 against perchild, only worker
> and threaded mpms [and win32, netware specific mpms.] As long as
> the changes to server/mpm/perchild are finished when we are ready
> to roll (probably tomorrow evening, giving folks a chance to test the
> APACHE_2_0_34 tag and uncover any issues, as Jerry Baker has
> already done) then I'm fine with including those changes.
Do we plan to test out 2.0.34 on daedalus before rolling? -- justin
RE: 2.0.34 up-to-date wrt cvs HEAD
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sun, 31 Mar 2002 22:46:35 -0500 (EST), Cliff Woolley wrote:
>On Sun, 31 Mar 2002, William A. Rowe, Jr. wrote:
>
>> I don't expect us to 'measure' 2.0.34 against perchild, only worker
>> and threaded mpms [and win32, netware specific mpms.]
>
>Speaking of MPMs, can I lean on the keepers of the other MPMs (OS/2, BeOS)
>to do me the favor of verifying that my changes at least compile and run
>on their platforms?
OS/2 mpm builds fine after your changes.
I can't say the same for the current HEAD though. I'm getting segfaults
processing most requests but that appears to be from today's bucket alloc
changes as a build after a "cvs up -D 20020401" in srclib works ok.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
RE: 2.0.34 up-to-date wrt cvs HEAD
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 31 Mar 2002, William A. Rowe, Jr. wrote:
> I don't expect us to 'measure' 2.0.34 against perchild, only worker
> and threaded mpms [and win32, netware specific mpms.]
Speaking of MPMs, can I lean on the keepers of the other MPMs (OS/2, BeOS)
to do me the favor of verifying that my changes at least compile and run
on their platforms?
Thanks!
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
RE: 2.0.34 up-to-date wrt cvs HEAD
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:36 PM 3/31/2002, you wrote:
>If it's possible, I would like to get the perchild changes that I am
>working on tonight into 2.0.34. I am tired of the reports that perchild
>doesn't compile. :-) I am hoping to have the whole thing working by
>the end of the day.
I don't expect us to 'measure' 2.0.34 against perchild, only worker
and threaded mpms [and win32, netware specific mpms.] As long as
the changes to server/mpm/perchild are finished when we are ready
to roll (probably tomorrow evening, giving folks a chance to test the
APACHE_2_0_34 tag and uncover any issues, as Jerry Baker has
already done) then I'm fine with including those changes.
Just email server/mpm/perchild/CVS/Entries to the list when you are
all 'set' :)
Bill
Re: 2.0.34 up-to-date wrt cvs HEAD
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Apr 01, 2002 at 12:09:35PM -0600, William A. Rowe, Jr. wrote:
> MPMs should never exist in modules/.
>
> I don't think a 'broken mpm' is any worse than an MPM that doesn't
> compile at all. But if you want to insist that --with-mpm=perchild yields
> some sort of "This MPM is experimental -- it is not expected to work
> at this time" ... that would be fine.
>
> But I see no reason not to fold these fixes into 2.0.34 unless they start
> touching files outside of server/mpm/perchild/
I'm not saying that we shouldn't include the perchild changes, I'm just
saying we shouldn't imply that by including them the perchild MPM is
any less experimental. In fact, I think we should go one step further
and create a server/mpm/experimental to put things like perchild,
leader-follower, door, and whatever else comes along.
I'm all for a message from the configure script, but I don't think that
it is obvious enough by itself.
-aaron
Re: 2.0.34 up-to-date wrt cvs HEAD
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:45 AM 4/1/2002, you wrote:
>On Sun, Mar 31, 2002 at 06:36:58PM -0800, Ryan Bloom wrote:
> > If it's possible, I would like to get the perchild changes that I am
> > working on tonight into 2.0.34. I am tired of the reports that perchild
> > doesn't compile. :-) I am hoping to have the whole thing working by
> > the end of the day.
>
>I'm not the RM, so it isn't up to me, but I'd prefer that we didn't
>include perchild in this tag/release. If it were more obvious that it
>is an experimental piece (by moving it to an experimental directory)
>then I'd be fine with any changes regardless of how much exposure the
>new changes have had.
MPMs should never exist in modules/.
I don't think a 'broken mpm' is any worse than an MPM that doesn't
compile at all. But if you want to insist that --with-mpm=perchild yields
some sort of "This MPM is experimental -- it is not expected to work
at this time" ... that would be fine.
But I see no reason not to fold these fixes into 2.0.34 unless they start
touching files outside of server/mpm/perchild/
Bill
Re: 2.0.34 up-to-date wrt cvs HEAD
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Mar 31, 2002 at 06:36:58PM -0800, Ryan Bloom wrote:
> If it's possible, I would like to get the perchild changes that I am
> working on tonight into 2.0.34. I am tired of the reports that perchild
> doesn't compile. :-) I am hoping to have the whole thing working by
> the end of the day.
I'm not the RM, so it isn't up to me, but I'd prefer that we didn't
include perchild in this tag/release. If it were more obvious that it
is an experimental piece (by moving it to an experimental directory)
then I'd be fine with any changes regardless of how much exposure the
new changes have had.
-aaron
RE: 2.0.34 up-to-date wrt cvs HEAD
Posted by Ryan Bloom <rb...@covalent.net>.
If it's possible, I would like to get the perchild changes that I am
working on tonight into 2.0.34. I am tired of the reports that perchild
doesn't compile. :-) I am hoping to have the whole thing working by
the end of the day.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Sunday, March 31, 2002 6:23 PM
> To: dev@httpd.apache.org
> Subject: Re: 2.0.34 up-to-date wrt cvs HEAD
>
> At 03:01 PM 3/31/2002, Cliff wrote:
>
> >The error you're getting is "pointers to functions with different
> >attributes". My only humble guess is that it's a problem with
> >apr_bucket_free() being APU_DECLARE'd and the parameter to
> >apr_bucket_heap_create/make() not specifying that. Does that sound
like
> a
> >logical hypothesis? If it's not that, I'm running out of ideas. If
it
> is
> >that, I still don't know how to fix it. :)
>
> With _NONSTD, which tells msvc that the function is to be declared
_cdecl
> (e.g. the usual void foo(void arg) declaration) as opposed to
_stdcall,
> which
> uses pascal - callee pops the args on return - convention.
>
> The patch is applied and the tag adjusted appropriately. Thanks for
> catching
> this one, Jerry, and good call Cliff!
>
> Bill