i'd like to port mod_iptos to 2.x http://arctic.org/~dean/mod_iptos/ ...
and preferably have it accepted into the main distribution.
in 1.3.x it was trivial to do mod_iptos as a module because all i had to
do was setsockopt(r-connection-client-fd, IPPROTO_IP, IP_TOS, ...).
i've already sent a
On Tue, 21 Aug 2001, Martin Kraemer wrote:
I don't know whether Dean Gaudet is still lurking, maybe he knows
whether there are reasons which forbid the use of the
-DNO_SEM_UNDO alternative in apache itself. I was under the
impression that nobody implemented it yet, but it would be useful
On Tue, 4 Sep 2001, Ryan Bloom wrote:
On Tuesday 04 September 2001 09:16, Justin Erenkrantz wrote:
Ryan, you may veto this commit. However, if you wish to repeal or
modify our style guide, I suggest you call a vote. -- justin
That is complete BS. We have a long standing tradition of
On Tue, 4 Sep 2001, Brian Pane wrote:
* Collectively, stat and open comprise 5% of the total CPU time.
It would be faster to do open+fstat rather than stat+open (as
long as the server is delivering mostly 200s rather than 304s),
but that might be too radical a change. Anybody have
why is there a need for 15 entries? if it's a multiprocess server then
there's only a need for 1 or 2 entries. if it's a multithreaded server
then you need to lock the cache (which you're not doing :)
isn't the real win in eliminating both the divisions required by the
explode time functions
On Thu, 30 Aug 2001, Dirk-Willem van Gulik wrote:
On Wed, 29 Aug 2001, Marc Slemko wrote:
There is nothing to test. Using the 1.3 process based model, you need
serialized accepts if you have multiple listening sockets. Period.
Unless your kernel socket or higher level accept filter's
On Tue, 28 Aug 2001, Ryan Bloom wrote:
Creating a pool requires locking a mutex. The more we scale, the worse we
perform.
a mutex is not a requirement... as i explained several months ago. (and
as greg mentioned, this patch just moves the mutex to the queue from the
pool code, which makes
On Mon, 10 Sep 2001, Brian Pane wrote:
dean gaudet wrote:
why is there a need for 15 entries? if it's a multiprocess server then
there's only a need for 1 or 2 entries. if it's a multithreaded server
then you need to lock the cache (which you're not doing :)
The whole point
On Wed, 15 Aug 2001, William A. Rowe, Jr. wrote:
. If the pool argument passed in merge_dir_configs doesn't match the base config,
it's out of scope! You must copy when the pool argument differs from the base!
. Likewise, if you are changing parts of the add config, and the add
On 12 Sep 2001, Ian Holsman wrote:
What I am suggesting is to move some of these configurations to
Location / where they belong.
+1.
-dean
On Tue, 11 Sep 2001, Greg Stein wrote:
On Tue, Sep 11, 2001 at 12:06:13AM -0500, William A. Rowe, Jr. wrote:
...
where the code uses a pid (getpid()) you need to use a concatenation of
pid and thread id.
otherwise you violate some of the uniqueness guarantees.
i just didn't
On Wed, 12 Sep 2001, Günter Knauf wrote:
For NetWare I found this definition in ./netware/os.h:
#define getpid GetThreadID
and in the NetWare header nwthread.h GetThreadID() is defined as:
int GetThreadID( void );
for Win32 platform getpid() is defined in process.h:
_CRTIMP int __cdecl
On Thu, 13 Sep 2001, Brad Nicholes wrote:
I checked with our CLIB people and they tell me that GetThreadID is
*not* unique. In other words, if a thread is created, it is assigned
an ID. If that thread is terminated and a new thread is created, the
new thread may reuse the ID from the
yeah i considered that, but i don't think rr-filename can be NULL in
1.3... 'cause i don't think you can get rr-status == OK with a NULL
filename...
the only calls to ap_translate_name() which succeed are followed by
ap_directory_walk() which tests for a NULL filename and sets it to a copy
of
On Thu, 20 Sep 2001, Ian Morgan wrote:
RecvTimeout 5
This will cause any incoming request to timeout if not completed within 5
seconds. This will cause the above null connections to timeout very
quickly, thereby significantly reducing the number of wasted waiting server
instances.
so the
On Tue, 18 Sep 2001, RCHAPACH Rochester wrote:
Yes, FD_SETSIZE is defined in sys/types.h on UNIX flavored
systems. If you set it to a high enough value
(i.e. #DEFINE FD_SETSIZE 65535 ) before sys/types.h gets included,
it will override the value set in sys/types.h.
this isn't portable.
you're misreading the RFC. spaces after the chunk-size are permitted,
look at section 2.1, Implied *LWS. the reason apache uses them is an
optimisation within the buffering routines to avoid an extra memcpy, and
this is one of the reasons the whitespace is permitted.
it's unfortunate, i would
On Thu, 27 Sep 2001, Brian Pane wrote:
The other big complication is that we'd need a way to avoid blocking
on disk reads if a client requests a file that isn't currently in the
filesystem cache. I guess mincore(2) would work in cases where we happen
to have the file mmap'ed, but is there a
my personal opinion is that most uses of pcalloc() are just lazy
programming.
if maintainability is an issue then make a creator function or macro for
your data structures.
the only thing empirical here is that the person doing the pcalloc to
palloc change wasn't thorough enough. it doesn't
fwiw, i've never used calloc. if i really need to memset something to 0
then i do it explicitly after the allocation.
why? the reason has nothing to do with the maintainability arguments
being presented here, and has everything to do with performance.
study the following code and assembly.
On Fri, 9 Nov 2001, Bill Stoddard wrote:
Curious what insite Dean had into suggesting a change from SIGALRM to
SIGUSR2.
the two places the children were hanging (in PR#3906) were in places that
the parent was supposed to deliver SIGALRM. they weren't hard hangs
because the SIGHUP was
On Mon, 12 Nov 2001, Ryan Bloom wrote:
I am trying to remove the network logic from the MPMs, so that modules can
implement different transport layers.
are you referring to multiplexing transport layers? 'cause what's there
already should work fine for non-multiplexed transports... i.e.
i tend to agree with greg... this all seems to be contrary to the original
MPM goals which was to provide a method of accessing the fastest and most
scalable socket - worker mapping on each platform. it looks like you're
making all the world have to function like unix.
-dean
On Tue, 13 Nov
On Tue, 13 Nov 2001, Ryan Bloom wrote:
On Tuesday 13 November 2001 04:35 pm, dean gaudet wrote:
On Mon, 12 Nov 2001, Ryan Bloom wrote:
I am trying to remove the network logic from the MPMs, so that modules
can implement different transport layers.
are you referring to multiplexing
On Sun, 4 Nov 2001, Brian Pane wrote:
3. Keep using apr_table_t for the fields in request_rec, and redesign
the internals of apr_table_t to support O(log(n)) access
whatever you do please remember to make sure you don't consume lots of
extra memory for the many tables which have only 1 or
On Wed, 14 Nov 2001, Stipe Tolj wrote:
I have reported such hanginf keepalive childs on the Cygwin 1.x
platform.
These come up after some days of load and ussually go up to 50-60
blocked keepalive childs. Recently (after 16 days httpd uptime) the
whole scoreboard flushed and the hanging
On Sat, 17 Nov 2001, Brian Pane wrote:
* A rewrite of apr_table_overlap() that uses a hash
table (sort of) instead of qsort
i'm not sure this part of the patch is a good idea. the reason
apr_table_overlap() uses qsort is to prevent various O(n^2) DoS attacks
(both time space). with
fyi: in 1.3.x this used to give an informative error on linux telling the
user to recompile their kernel for sysv ipc support.
(i'm assuming ap_mm_create is a 2.0 symbol name...?)
-dean
-- Forwarded message --
Date: Tue, 20 Nov 2001 20:30:34 -0500
To: [EMAIL PROTECTED]
From:
hey -- i was just cleaning out my [EMAIL PROTECTED] mailbox (so much spam :)
and found this. it appears to be a bug i fixed in 1.3 but the fix wasn't
applied to 2.0? is there any general plan to sweep through 1.3 fixes and
merge them into 2.0?
-dean
-- Forwarded message --
[a little birdie said folks were quoting me ;) hi!]
On 16 Sep 2002, Brian Pane wrote:
Linux kernel modules are a special case due to some characteristics
that don't apply to Apache:
* Most Linux kernel modules are available in source form
most are available in source form simply because
can anyone remember, or explain why, redirect /foo /bar isn't permitted,
but redirectmatch /foo /bar is? (i haven't looked to see if this
bizarreness is fixed in 2.0 or not.)
-dean
31 matches
Mail list logo
