Ian Holsman wrote:
i'm just about to talk to * who are going to do some static specweb
tests with apache2
any tips you would like to share with them ???
yeah.
* When you source the shrc file, don't expect to see any output. It just sets
some envvars.
* Look at the SPECWeb99 results
Also - hack the conf to do short runs first !
Oh yeah, excellent point. That's the SPEC rc file. Look for *_TIME,
ITERATIONS, and SIMULTANEOUS_CONNECTIONS.
My rc files usually have trial (short) values for *_TIME and a single
iteration. You can force all those in line for a compliant run
On Fri, Aug 16, 2002 at 06:53:54AM -, [EMAIL PROTECTED] wrote:
jerenkrantz2002/08/15 23:53:54
Modified:docs/manual/developer thread_safety.html
Log:
Add note on c-client based on evidence from c-client mailing list archives
and, in particular, Mark Crispin's posts.
On Thu, Aug 15, 2002 at 12:17:24PM -0700, Rasmus Lerdorf wrote:
Yup, definitely. They aren't always open source or sometimes they are
just architecturally not fixabled. Step 1 is to gather information. I
have committed an initial short list to
[Posting for comments before I commit, because the
core filter code is somewhat complex...]
With the current core_output_filter() implementation,
if the client requests a file smaller than 8KB, the
filter reads the file bucket, makes a copy of the
contents, and sets the copy aside in hopes of
This is a particularly interesting case as Mark is pretty adamant
that strtok() and gethostbyname() should be thread-safe and the fact
that it isn't on most platforms doesn't persuade him to use
strtok_r() or gethostbyname_r() if available. (Not that I disagree
with him here - these
On Thu, Aug 15, 2002 at 12:17:24PM -0700, Rasmus Lerdorf wrote:
Yup, definitely. They aren't always open source or sometimes they are
just architecturally not fixabled. Step 1 is to gather information. I
have committed an initial short list to
This is a particularly interesting case as Mark is pretty adamant
that strtok() and gethostbyname() should be thread-safe and the fact
that it isn't on most platforms doesn't persuade him to use
strtok_r() or gethostbyname_r() if available. (Not that I disagree
with him here - these
This possibly follows an earlier message:
[EMAIL PROTECTED]
2002/08/14 00:07:44 commit of cache_pqueue.h changed typedefs for
callbacks from function declarations to function pointers. Following
this, cache_cache(_make_money_fast).c failed to compile. I could fix
either, but being strongly in
Wilfredo Sanchez wrote:
OK, so do people really hate the IfModule wrappers? Because I
wanna commit it. Votes?
We have +1 from Fred, Ian and a 0 of some flavor from Joshua.
+1 from me
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer,
On Fri, Aug 16, 2002 at 09:55:16AM -0400, Eric Prud'hommeaux wrote:
This possibly follows an earlier message:
[EMAIL PROTECTED]
2002/08/14 00:07:44 commit of cache_pqueue.h changed typedefs for
callbacks from function declarations to function pointers. Following
this,
We had this discussion elsewhere, but just for the record..
Justin Erenkrantz wrote:
And, my point back to you is that should be part of the documentation
of the module NOT of httpd-2.0.
IMNSHO, that is *such* BS. If someone has a working Web server
and upgrades following our
At 10:41 AM 8/16/2002, Rodent of Unusual Size wrote:
And, my point back to you is that should be part of the
documentation
of the module NOT of httpd-2.0.
IMNSHO, that is *such* BS. If someone has a working Web server and
upgrades following our recommendations, and things stop working,
At 09:41 AM 8/16/2002, Rodent of Unusual Size wrote:
We had this discussion elsewhere, but just for the record..
Justin Erenkrantz wrote:
And, my point back to you is that should be part of the documentation
of the module NOT of httpd-2.0.
IMNSHO, that is *such* BS. If someone has a
I don't see what the big deal is here. It doesn't have to be one or
the other. It REALLY is up to PHP and mod_perl to let their users
know that they aren't thread-safe. It would also be helpful for
Apache to let its users know that there are potential problems due to
non-thread-safe
Rodent of Unusual Size wrote:
What changed? The Web server; it started supporting threads.
only if the user explicitly does ./configure --with-mpm=something threaded on
Unix
So it
behooves the Web server to document the potential for problems. Why
should the burden be put on PHP, or
On Fri, 16 Aug 2002, Eric Prud'hommeaux wrote:
This possibly follows an earlier message:
[EMAIL PROTECTED]
Yes, it does. I meant to fix this yesterday but then the power went out
in my building. :-( I'll fix it today.
--Cliff
At 10:21 AM 8/16/2002, Bill Stoddard wrote:
A remarkable number of software developers are really ignorant about
programming in a threaded environment and I know from first hand experience
with newbie software developers that it is really difficult for some people
to grok that even a one
William A. Rowe, Jr. wrote:
At 10:21 AM 8/16/2002, Bill Stoddard wrote:
A remarkable number of software developers are really ignorant about
programming in a threaded environment and I know from first hand experience
with newbie software developers that it is really difficult for some
On Fri, Aug 16, 2002 at 09:35:21AM +0200, Sascha Schumann wrote:
That is clearly wishful thinking -- strtok/gethostbyname are
legacy, non-reentrant APIs according to POSIX/SUSv3.
Oh, of course.
What's his problem with the reentrant APIs? Is the cost of
transition too
On Fri, Aug 16, 2002 at 12:34:11AM -0700, Brian Pane wrote:
[Posting for comments before I commit, because the
core filter code is somewhat complex...]
Looks correct based on my examination. +1. -- justin
Rodent of Unusual Size wrote:
We had this discussion elsewhere, but just for the record..
Justin Erenkrantz wrote:
And, my point back to you is that should be part of the documentation
of the module NOT of httpd-2.0.
IMNSHO, that is *such* BS. If someone has a working Web server
and
On Fri, Aug 16, 2002 at 11:41:53AM -0400, Jim Jagielski wrote:
William A. Rowe, Jr. wrote:
At 10:21 AM 8/16/2002, Bill Stoddard wrote:
A remarkable number of software developers are really ignorant about
programming in a threaded environment and I know from first hand experience
with
From: Auriemma Luigi [EMAIL PROTECTED]
Organization: PivX
To: [EMAIL PROTECTED]
Subject: Apache 2.0.39 directory traversal and path disclosure bug
Date: Fri, 16 Aug 2002 17:01:29 +
##
Auriemma Luigi, PivX security advisory
Date: Fri, 16 Aug 2002 11:39:04 -0500
To: Auriemma Luigi [EMAIL PROTECTED]
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Subject: Re: Apache 2.0.39 directory traversal and path disclosure bug
Cc: [EMAIL PROTECTED]
At 12:01 PM 8/16/2002, Auriemma Luigi wrote:
B) CAN-2002-0661
The following bug was found to affect all platforms and is fixed in 2.0.40
as part of the CAN-2002-0654 incident;
Date: Mon, 29 Jul 2002 15:27:03 -0700
From: Jim Race [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Security regression in 2.0.39 (Win32)?
In previous versions of 2.0.n, there was
While trying to create a simple testcase demonstrating a bug in the xlc
compiler, I did a little experiment. Here is a code snip from core.c:
snip
/* Code from core.c */
if (mode == AP_MODE_INIT) {
return APR_SUCCESS;
}
if (!ctx)
{
ctx = apr_pcalloc(f-c-pool, sizeof(*ctx));
Bill Stoddard wrote:
And here is that same code with the macros unrolled. The xlc
optimizer chokes on this. This is just nasty.
/me vomits
I've hated the concealment of code inside these macros from
Day 1. One or two lines of code in a macro, fine; functionality
like this.. megasuckage.
--
On Fri, 16 Aug 2002, Bill Stoddard wrote:
And here is that same code with the macros unrolled. The xlc optimizer
chokes on this. avoid_xlc_bug() just returns 1 and does nothing else (and
makes the optimzer happy again). This is just nasty.
Can you be more specific about what the bug is,
Bill Stoddard wrote:
While trying to create a simple testcase demonstrating a bug in the xlc
compiler, I did a little experiment. Here is a code snip from core.c:
I'm just wondering if there is any kind of measureable performance
benefit in keeping these as a macro vs putting them in a
On Fri, 16 Aug 2002, Ian Holsman wrote:
I'm just wondering if there is any kind of measureable performance
benefit in keeping these as a macro vs putting them in a function
(possibly inline if the compiler can support it).
I'm quite sure there is a performance benefit, though admittedly I
On Fri, 16 Aug 2002, Cliff Woolley wrote:
On Fri, 16 Aug 2002, Ian Holsman wrote:
I'm just wondering if there is any kind of measureable performance
benefit in keeping these as a macro vs putting them in a function
(possibly inline if the compiler can support it).
I'm quite sure
Ian Holsman wrote:
Bill Stoddard wrote:
While trying to create a simple testcase demonstrating a bug in the xlc
compiler, I did a little experiment. Here is a code snip from core.c:
I'm just wondering if there is any kind of measureable performance
benefit in keeping these as a
On Fri, 16 Aug 2002, Ryan Bloom wrote:
A better question IMHO, is whether any of those macros can be made less
complex.
It's a good question, but IMO the answer is no. The ring macros are very
tight and easy to read... like I said, they're about four lines each.
The brigade macros are, for
On Fri, 16 Aug 2002, Cliff Woolley wrote:
On Fri, 16 Aug 2002, Ryan Bloom wrote:
A better question IMHO, is whether any of those macros can be made less
complex.
It's a good question, but IMO the answer is no. The ring macros are very
tight and easy to read... like I said, they're
Is striker going to be signing apache releases from now on?
Previously the tarballs were signed by Cliff Woolley.
2.0.40 is signed by Sander Striker, and the KEYS file keeps on growing :)
On Thu, 15 Aug 2002, William A. Rowe, Jr. wrote:
There's no reason to bloat all of Apache and it's well behaved modules
with extra code, when only a handful of modules care to report that they
can't be compiled for a threaded architecture.
The strict engineer in me agrees. The pragmatic
patches (2 currently, typedefFuncs-20020816.patch and
diskCache-20020816.patch).
Despite these todos, I believe it is a good idea to integrate this
patches as disk caching doesn't really work now so they at least
improve the situation.
--
-eric
([EMAIL PROTECTED])
Feel free to forward
I have to screw at least one thing up per post.
Here are the promised attachments...
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
diskCache-test-20020816.tar.gz
Description: application/tar-gz
work when would have had to fail anyways.
-Add HTTP Extensions support to the cache validity calculation. I have
patches for this, but I'll wait 'till I've got fewer outstanding
patches (2 currently, typedefFuncs-20020816.patch and
diskCache-20020816.patch).
Despite these todos, I believe
40 matches
Mail list logo
