On Thu, 28 Aug 2003 02:07:40 -0400 (EDT), Cliff Woolley wrote:
On Thu, 28 Aug 2003 [EMAIL PROTECTED] wrote:
jwoolley2003/08/27 22:54:44
Modified:.CHANGES
server/mpm/beos beos.c
server/mpm/experimental/leader leader.c
On Thu, 28 Aug 2003 [EMAIL PROTECTED] wrote:
jwoolley2003/08/27 22:54:44
Modified:.CHANGES
server/mpm/beos beos.c
server/mpm/experimental/leader leader.c
server/mpm/experimental/threadpool threadpool.c
On Thu, 28 Aug 2003 [EMAIL PROTECTED] wrote:
Index: threadpool.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/experimental/threadpool/threadpool.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -u
* Sander Striker ([EMAIL PROTECTED]) wrote :
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2002 02:41
[...]
Log:
Catch up with the apr_allocator_set_owner - apr_allocator_owner_set renames
in APR.
This requires an MMN bump (which is fine with me, since
On Wed, May 29, 2002 at 08:40:55PM -0400, Cliff Woolley wrote:
On 30 May 2002 [EMAIL PROTECTED] wrote:
striker 02/05/29 17:21:27
Modified:server/mpm/beos beos.c
server/mpm/experimental/leader leader.c
server/mpm/experimental/threadpool
On 30 May 2002 [EMAIL PROTECTED] wrote:
striker 02/05/29 17:21:27
Modified:server/mpm/beos beos.c
server/mpm/experimental/leader leader.c
server/mpm/experimental/threadpool threadpool.c
server/mpm/netware mpm_netware.c
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2002 02:41
[...]
Log:
Catch up with the apr_allocator_set_owner - apr_allocator_owner_set renames
in APR.
This requires an MMN bump (which is fine with me, since we've already done
one in 2.0.37-dev, and I'm starting
[EMAIL PROTECTED] writes:
jerenkrantz02/05/01 00:15:40
Modified:.CHANGES
server/mpm/worker worker.c
Log:
Close sockets on worker MPM when doing a graceless restart. This should
resolve some segfaults see when doing such restarts.
(My apologies for
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick
Sent: 01 May 2002 14:53
[EMAIL PROTECTED] writes:
jerenkrantz02/05/01 00:15:40
Modified:.CHANGES
server/mpm/worker worker.c
Log:
Close sockets on worker MPM when
Hi,
I was going to roll 2.0.36, but I want to wait for this last
worker change. Unfortunately I don't have the time to pursue
the issue now, so if someone does, please feel free to take
care of this annoying beast.
Sander
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: 01 May 2002
Sander Striker [EMAIL PROTECTED] writes:
Hi,
I was going to roll 2.0.36, but I want to wait for this last
worker change. Unfortunately I don't have the time to pursue
the issue now, so if someone does, please feel free to take
care of this annoying beast.
I'll start working on it now.
Sander Striker wrote:
I was going to roll 2.0.36, but I want to wait for this last
worker change. Unfortunately I don't have the time to pursue
the issue now, so if someone does, please feel free to take
care of this annoying beast.
BTW: Is there any problem with the CVS version of
On Wed, May 01, 2002 at 07:15:40AM -, Justin Erenkrantz wrote:
jerenkrantz02/05/01 00:15:40
Modified:.CHANGES
server/mpm/worker worker.c
Log:
Close sockets on worker MPM when doing a graceless restart. This should
resolve some segfaults see when
On Wed, May 01, 2002 at 12:22:13PM -0700, Aaron Bannert wrote:
I did not post this so that you could commit it before I thought it had
been properly reviewed. On top of that you modified my original patch
in a way that you knew I would disagree with. Please do not do that again.
Sorry. My
And, consider my position on your calloc change in this patch as a
veto. If you want to remove calloc, then you should do so throughout
the code rather than in sporadic places that may make maintaining the
code a nightmare if we were to fix calloc. But, that is an issue
that is now open in
On Wednesday, May 1, 2002, at 01:49 PM, Aaron Bannert wrote:
And, consider my position on your calloc change in this patch as a
veto. If you want to remove calloc, then you should do so throughout
the code rather than in sporadic places that may make maintaining the
code a nightmare if we
On Wed, 1 May 2002, Aaron Bannert wrote:
safe_free()-like stuff does, but at least it is a compromise. OTOH,
as Cliff brought up, we'll get a SEGV if apr_palloc() returns NULL.
Whoa, slow down. I said that was an argument someone had once posed, but
I also said I thought it was ridiculous.
safe_free()-like stuff does, but at least it is a compromise. OTOH,
as Cliff brought up, we'll get a SEGV if apr_palloc() returns NULL.
Whoa, slow down. I said that was an argument someone had once posed, but
I also said I thought it was ridiculous. We just don't need to worry
about
Because we have to keep the old API working, and because duplicating code
everywhere is a bad thing.
How is it duplicated? This is new code.
And while we are on the topic, anything that is posted to the mailing
list is open for others to commit to the code base. That is how we work.
On Wed, 1 May 2002, Aaron Bannert wrote:
- Does this work on ... (linux)?
Yes, it seems to. Something else is screwy, but as a whole, it kind of
works at least, and this piece in particular seems to be doing fine.
--Cliff
--
On Sat, Apr 27, 2002 at 07:30:51PM -0700, Justin Erenkrantz wrote:
+qi = apr_palloc(pool, sizeof(*qi));
+memset(qi, 0, sizeof(*qi));
As we said, if you are concerned about the performance aspect
of apr_pcalloc, then we should fix apr_pcalloc NOT attempt to
work
Bill Stoddard wrote:
On Sat, Apr 27, 2002 at 07:30:51PM -0700, Justin Erenkrantz wrote:
+qi = apr_palloc(pool, sizeof(*qi));
+memset(qi, 0, sizeof(*qi));
As we said, if you are concerned about the performance aspect
of apr_pcalloc, then we should fix apr_pcalloc NOT attempt to
Comments inline.
On Sun, Apr 28, 2002 at 01:45:00AM -, [EMAIL PROTECTED] wrote:
1.16 +108 -0httpd-2.0/server/mpm/worker/fdqueue.c
Index: fdqueue.c
===
RCS file:
On Sat, Apr 27, 2002 at 07:30:51PM -0700, Justin Erenkrantz wrote:
+qi = apr_palloc(pool, sizeof(*qi));
+memset(qi, 0, sizeof(*qi));
As we said, if you are concerned about the performance aspect
of apr_pcalloc, then we should fix apr_pcalloc NOT attempt to
work around its
On Sat, Apr 27, 2002 at 07:39:24PM -0700, Brian Pane wrote:
I was going to complain about the addition of yet another mutex
to the critical path of request processing, but it got me thinking
about an approach to making worker faster: shorten the time spent
in the mutex-protected region.
Yes!
-Original Message-
From: Brian Pane [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 17, 2002 7:48 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Rose, Billy wrote:
If I could receive feedback on the following email made on
the 11th
: Wednesday, April 17, 2002 3:19 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Wed, Apr 17, 2002 at 02:58:03PM -0500, Rose, Billy wrote:
If I could receive feedback on the following email made on
the 11th, I'd be
willing to burn some hours to make
Striker [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 18, 2002 9:00 AM
To: [EMAIL PROTECTED]
Cc: Billy Rose
Subject: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
From: Rose, Billy [mailto:[EMAIL PROTECTED]]
Sent: 18 April 2002 15:47
Hummm. What are your thoughts on shmget
My point was you can't simply copy integers across processes, they won't
map to the same vnode. You must use a mechanism for passing them between
these processes, and this comes at a price.
If you're looking for a cross-platform shared-memory implementation,
APR's got it: apr_shm.h
If you want
Isn't this the introduction of a memory leak?
The threads keep being created, and the pool is _never_
cleared.
Sander
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 17 April 2002 17:45
To: [EMAIL PROTECTED]
Subject: cvs commit: httpd-2.0/server/mpm
Aren't global pools still cleaned up on exit? If the threads are still
running we'll still have the same problem. The only way I see to fix this
is to make sure that all threads have terminated before cleaning up
the pool.
I don't see that they're getting cleaned up on exit.
Pools
On 29 Mar 2002 [EMAIL PROTECTED] wrote:
jwoolley02/03/29 00:17:26
Modified:. damn near everything
Log:
BUCKET FREELISTS
Add an allocator-passing mechanism throughout the bucket brigades API.
Yep, that's it... the beast is finally in. I've tested to the best of my
[EMAIL PROTECTED] wrote:
jim 02/03/29 06:33:51
Modified:.CHANGES
include scoreboard.h
os/tpf os.c
server scoreboard.c
server/mpm/netware mpm_netware.c
server/mpm/prefork prefork.c
not sure if this is related to the bucket list change or mod_includes
changes or what, but i just checked in a test adapted from modperl that
dumps core. stacktrace below from t/TEST t/modules/include2.t
#0 0x0815a897 in ?? () at eval.c:41
41 eval.c: No such file or directory.
another problem after fixing the httpd-test c-modules to compile:
t/apache/passbrigade eats all cpu. have not looked into it.
Line 3186 in mod_include is hit when it has run through the whole brigade and
found no tags. It is just forwarding the brigade. This will be the normal
case for files that get parsed unnecessarily. This seems to work for me.
No brigades are harmed in this process. I suspect that there is another
On Fri, 29 Mar 2002, Doug MacEachern wrote:
another problem after fixing the httpd-test c-modules to compile:
t/apache/passbrigade eats all cpu. have not looked into it.
nevermind. i didn't notice the modules had been updated and my cvs commit
up-to-date check failed. this test is working
On Fri, 29 Mar 2002, Doug MacEachern wrote:
not sure if this is related to the bucket list change or mod_includes
changes or what, but i just checked in a test adapted from modperl that
dumps core. stacktrace below from t/TEST t/modules/include2.t
fyi: t/php/virtual produces the same
On Fri, 29 Mar 2002, Doug MacEachern wrote:
fyi: t/php/virtual produces the same stacktrace
I'll look into this this afternoon. Has PHP really been updated for the
new buckets API already??
--Cliff
--
Cliff Woolley
[EMAIL
On Fri, 29 Mar 2002, Cliff Woolley wrote:
On Fri, 29 Mar 2002, Doug MacEachern wrote:
fyi: t/php/virtual produces the same stacktrace
I'll look into this this afternoon.
great. probably easier to work with t/modules/include2.t, stacktrace
looks like they suffer the same problem.
[EMAIL PROTECTED] writes:
wrowe 02/03/19 21:58:21
Modified:server/mpm/beos beos.c
server/mpm/netware mpm_netware.c
server/mpm/perchild perchild.c
server/mpm/prefork prefork.c
server/mpm/winnt mpm_winnt.c
Log:
The pre_mpm hook creates server-lifetime objects (or at least,
for
the
generations across graceful restarts.) They should use the
process
pool.
The pre_mpm hook doesn't seem generically useful. It seems to be tied
to our current idea of how the scoreboard should be
[EMAIL PROTECTED] wrote:
+/* XXX unfortunate issue:
+ * with apachectl restart (not graceful), previous generation dies
+ * abruptly with no chance to clean up scoreboard entries; when new
+ * generation is started, processes can loop forever in start_threads()
+ *
Greg Ames wrote:
[EMAIL PROTECTED] wrote:
+/* XXX unfortunate issue:
+ * with apachectl restart (not graceful), previous generation dies
+ * abruptly with no chance to clean up scoreboard entries; when new
+ * generation is started, processes can loop forever in
[EMAIL PROTECTED] writes:
jim 02/03/20 08:44:13
Modified:.CHANGES
include mpm_common.h
server mpm_common.c
server/mpm/mpmt_os2 mpmt_os2.c
server/mpm/netware mpm_netware.c
Jeff Trawick wrote:
Bring 2.0 up to parity, a bit, with how much info we provide to
the admin regarding valid values for AcceptMutex. Should also
tell 'em what default actually maps to, but that can wait.
I don't think this works as you desired.
I just did an update (no diffs
Jim Jagielski [EMAIL PROTECTED] writes:
Jeff Trawick wrote:
Bring 2.0 up to parity, a bit, with how much info we provide to
the admin regarding valid values for AcceptMutex. Should also
tell 'em what default actually maps to, but that can wait.
I don't think this works as
On Wed, Mar 20, 2002 at 12:41:21PM -0500, Jim Jagielski wrote:
Actually, it does exactly what I intended, for the present. :)
Agreed, and this is part of what I alluded to above about tell 'em
what default is... For right now, since TAKE1 is a macro, you
can't use normal preprocessor foo
Aaron Bannert wrote:
Accept mutexes should all be apr_proc_mutex_t types, since the apr_lock_t
type is being phased out and will be soon removed from APR.
And that's the other issue as well... Let that settle down first :)
--
Jeff Trawick wrote:
It doesn't look too cool :)
I agree! :)
You don't have to use the macro (of course that extra type-checking
via the designated initializers is nice)...
If you use the macro, couldn't you pass a variable to the macro, and
use the preprocessor to build the string
On Wed, Mar 20, 2002 at 01:01:07PM -0500, Jim Jagielski wrote:
Accept mutexes should all be apr_proc_mutex_t types, since the apr_lock_t
type is being phased out and will be soon removed from APR.
And that's the other issue as well... Let that settle down first :)
I made an attempt to
Yes, the perchild one was the main one that concerned me...
Aaron Bannert wrote:
On Wed, Mar 20, 2002 at 01:01:07PM -0500, Jim Jagielski wrote:
Accept mutexes should all be apr_proc_mutex_t types, since the apr_lock_t
type is being phased out and will be soon removed from APR.
And
Jeff Trawick [EMAIL PROTECTED] writes:
Jim Jagielski [EMAIL PROTECTED] writes:
Jeff Trawick wrote:
Bring 2.0 up to parity, a bit, with how much info we provide to
the admin regarding valid values for AcceptMutex. Should also
tell 'em what default actually maps to, but
I think I have a version that addresses the concerns... running out to
a quick meeting, so I'll test and post a bit later...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society
Jim Jagielski [EMAIL PROTECTED] writes:
Ideally, this should be localized... other entities may want that info
and we don't want to have implementations spread out...
But the code passes check here as well.
I'll add this in once the lock stuff settles, unless it bothers you enough
that
[EMAIL PROTECTED] writes:
trawick 02/03/20 11:53:19
Modified:server/mpm/worker worker.c
Log:
write a debug message to the log when we're stuck in the sicko state
of trying to take over scoreboard slots that aren't going to be released
(we could also be stalled while
Jeff Trawick wrote:
No big hurry... I just didn't think it was intended to be the way it
is currently committed.
We needed some way to indicate valid mutex methods, and the change in
TAKE1 didn't allow the quote concats. Using a const char array is a
good idea, but I was loath to use a
I disagree with this patch. If we are getting failures on locks
then we have a bug somewhere and I'd rather not see us cover up
the problem by decreasing the verbosity.
-aaron
On Tue, Mar 05, 2002 at 09:18:07PM -, [EMAIL PROTECTED] wrote:
trawick 02/03/05 13:18:07
Modified:
Aaron Bannert [EMAIL PROTECTED] writes:
I disagree with this patch. If we are getting failures on locks
then we have a bug somewhere and I'd rather not see us cover up
the problem by decreasing the verbosity.
Here is the sequence of events:
1) a thread in child process A is waiting on
On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote:
Here is the sequence of events:
1) a thread in child process A is waiting on semaphore
2) graceful restart triggered
3) parent process cleans up the semaphore
4) that thread in child process A gets a failure (EIDRM) from the
Aaron Bannert [EMAIL PROTECTED] writes:
On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote:
Here is the sequence of events:
1) a thread in child process A is waiting on semaphore
2) graceful restart triggered
3) parent process cleans up the semaphore
4) that thread in
On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote:
Aaron Bannert [EMAIL PROTECTED] writes:
On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote:
Here is the sequence of events:
1) a thread in child process A is waiting on semaphore
2) graceful restart
Aaron Bannert [EMAIL PROTECTED] writes:
On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote:
Aaron Bannert [EMAIL PROTECTED] writes:
On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote:
Here is the sequence of events:
1) a thread in child process A is
On Tue, Mar 05, 2002 at 07:02:46PM -0500, Jeff Trawick wrote:
Will they actually hold the semaphore while they are servicing long-lived
connections?
no the semaphore is held only during the poll+accept
I guess we'd have to make it so that as soon as that worker*
is done
Aaron Bannert [EMAIL PROTECTED] writes:
On Tue, Mar 05, 2002 at 07:02:46PM -0500, Jeff Trawick wrote:
Will they actually hold the semaphore while they are servicing long-lived
connections?
no... the semaphore is held only during the poll+accept
I guess we'd have
On Thu, Feb 14, 2002 at 02:48:19AM -, [EMAIL PROTECTED] wrote:
aaron 02/02/13 18:48:19
Modified:server/mpm/worker worker.c
Log:
Retain signal handling in the worker MPM for the one_process case
(httpd with -DDEBUG, -X, or -DONE_PROCESS).
Fix -X, -DNO_DETACH,
Message -
From: Bill Stoddard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 04, 2002 11:57 AM
Subject: Fw: cvs commit: httpd-2.0/server/mpm/worker worker.c
This patch seems to have broken restarts and child recovery on Windows.
Investigating...
Bill
rbb 02/01/30 14:35
]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
-Original Message-
From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 8:58 AM
To: [EMAIL PROTECTED]
Subject: Fw: cvs commit: httpd-2.0/server/mpm/worker worker.c
This patch seems
On Mon, Feb 04, 2002 at 01:01:49PM -0500, Bill Stoddard wrote:
Actually, this patch is not the only (or even main) culprit. The switch to use the
shared
scoreboard is fatally broken. I am in the process of keeping the spirit of Ryan's
patch to
only use pre_mpm in the parent and revert back
, February 04, 2002 10:04 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Start apache as a service. That seems to make a difference.
Bill
I'm not having this problem. I just started Apache, and killed off
the
child process five
From: Bill Stoddard [EMAIL PROTECTED]
Sent: Monday, February 04, 2002 12:01 PM
Actually, this patch is not the only (or even main) culprit. The switch to use the
shared
scoreboard is fatally broken. I am in the process of keeping the spirit of Ryan's
patch to
only use pre_mpm in the
Modified:.CHANGES STATUS
server/mpm/perchild perchild.c
server/mpm/prefork prefork.c
server/mpm/worker worker.c
Log:
Not being able to bind to a socket is a fatal error. This makes all
MPMs treat it as such. We now print a
I finally had time to review this patch, and I have some comments.
Log:
This patch restores most of Ryan's patch (11/12/2001) to remove the
client_socket from the conn_rec. Diffs from Ryan's patch include:
- rename the create_connection hook to install_transport_filters
- move
[EMAIL PROTECTED] wrote:
trawick 02/01/30 03:56:26
Modified:server/mpm/worker worker.c
Log:
get rid of a bunch of warnings about unused variables
Thanks for catching that. I really need to start adding
-Wall to all my makefiles
--Brian
stoddard02/01/27 04:52:08
Modified:.CHANGES
include http_connection.h httpd.h
modules/http http_core.c
modules/proxy proxy_ftp.c proxy_http.c
server connection.c core.c
server/mpm/beos beos.c
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, January 27, 2002 3:05 PM
Subject: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
stoddard02/01/27 04:52:08
Modified:.CHANGES
include http_connection.h httpd.h
- Original Message -
From: Ryan Bloom [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, January 27, 2002 3:05 PM
Subject: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
stoddard02/01/27 04:52:08
Modified:.CHANGES
: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Ryan, you are vetoing my veto. Consider this patch a veto of your
11/12
patch. I am open
to suggestions to determine a compromise.
I need to replace core_in and core_out based on configuration. How can
I
do that with your
patch
On Sun, 27 Jan 2002, Bill Stoddard wrote:
1) Do exactly what I told you to do when I committed the patch
originally. Let's take an example of SSL. Your SSL vhost must know
which socket it is on, because it can't be on a plain HTTP socket. So,
for that socket, you replace the
On Sun, 27 Jan 2002, Bill Stoddard wrote:
1) Do exactly what I told you to do when I committed the patch
originally. Let's take an example of SSL. Your SSL vhost must know
which socket it is on, because it can't be on a plain HTTP socket. So,
for that socket, you replace the
[EMAIL PROTECTED] wrote:
brianp 02/01/11 00:01:11
Modified:.CHANGES
server/mpm/worker worker.c
Log:
Fix for a segfault in the worker MPM during graceful shutdown:
The per-transaction pools in the worker MPM can't be children of
the listener thread's
[EMAIL PROTECTED] writes:
brianp 02/01/11 00:01:11
Modified:.CHANGES
server/mpm/worker worker.c
Log:
Fix for a segfault in the worker MPM during graceful shutdown:
The per-transaction pools in the worker MPM can't be children of
the listener
This also fixes the shutdown issue with worker MPM on FreeBSD which is good
:)
david
brianp 02/01/11 00:01:11
Modified:.CHANGES
server/mpm/worker worker.c
Log:
Fix for a segfault in the worker MPM during graceful shutdown:
The per-transaction
Is this the same issue I just reported with:
Subject: [HEAD] --with-mpm=worker under FreeBSD 4.5 does nothing?
If so, then there is another bug in there somewhere, since I just checked,
and I'm running v1.60 of worker.c:
revision 1.60
date: 2002/01/11 08:01:11;
Brian,
Can you check and remove the showstopper if it solves the problem?
david
aaron 01/12/27 09:06:40
Modified:server/mpm/worker worker.c
Log:
Take advantage of the new usable apr_thread_exit().
Aaron updated the STATUS file already to remove the showstopper
--Brian
David Reid wrote:
Brian,
Can you check and remove the showstopper if it solves the problem?
david
aaron 01/12/27 09:06:40
Modified:server/mpm/worker worker.c
Log:
Take advantage of the new usable
Ugh! I've been meaning to patch the prototype for apr_thread_exit for
a long time (so that it takes an apr_status_t instead of a pointer), but
it got lost in the shuffle. I'll see if I can fix this sometime this week
so we don't have to have ackward rv stuff like this.
-aaron
On Sun, Dec 23,
On Mon, Nov 12, 2001 at 11:49:08PM -, [EMAIL PROTECTED] wrote:
...
--- httpd.h 2001/10/23 17:26:57 1.168
+++ httpd.h 2001/11/12 23:49:06 1.169
...
+typedef struct core_output_filter_ctx {
+apr_bucket_brigade *b;
+apr_pool_t *subpool; /* subpool of c-pool used
Ryan Bloom wrote:
On Monday 12 November 2001 09:48 pm, Justin Erenkrantz wrote:
[...]
modules/proxy/proxy_connect.c does raw socket writes (see line
308). I think the idea here is that mod_proxy wants to bypass
everyone. Not the greatest of ideas (quite bogus actually) -
perhaps we can setup
--- perchild.c2001/11/10 18:26:29 1.82
+++ perchild.c2001/11/12 23:49:07 1.83
@@ -502,7 +502,7 @@
ap_sock_disable_nagle(sock);
}
-current_conn = ap_new_connection(p, ap_server_conf, sock,
conn_id); +current_conn =
On Mon, Nov 12, 2001 at 11:49:08PM -, [EMAIL PROTECTED] wrote:
rbb 01/11/12 15:49:08
Log:
Begin to abstract out the underlying transport layer.
The first step is to remove the socket from the conn_rec,
the server now lives in a context that is passed to the
core's
On Monday 12 November 2001 09:48 pm, Justin Erenkrantz wrote:
On Mon, Nov 12, 2001 at 11:49:08PM -, [EMAIL PROTECTED] wrote:
rbb 01/11/12 15:49:08
Log:
Begin to abstract out the underlying transport layer.
The first step is to remove the socket from the conn_rec,
PM
Subject: cvs commit: httpd-2.0/server/mpm/worker worker.c
rbb 01/11/10 10:26:30
Modified:include http_connection.h
server connection.c
server/mpm/beos beos.c
server/mpm/mpmt_os2 mpmt_os2_child.c
server/mpm
: Bill Stoddard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 10, 2001 3:37 PM
Subject: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Ryan,
I understand the motivation for this, but it breaks Windows. In some cases we do not
want
to close the socket on Windows; it can
On Saturday 10 November 2001 12:37 pm, Bill Stoddard wrote:
Ryan,
I understand the motivation for this, but it breaks Windows. In some cases
we do not want to close the socket on Windows; it can be reused for a big
performance boost.
I'm fixing it. This is going to require me to re-export
On Saturday 10 November 2001 12:58 pm, Bill Stoddard wrote:
Sorry, my last message wasn't a very useful...
ap_lingering_close() should be conditionally called based on a feature
macro. Something like: HAVE_REUSE_ACCEPT_SOCKET. If the OS supports
reusing the accept socket, conditionally
On a largely unrelated note, but something I found a little ironic given
the nature of this list:
Aaron Bannert wrote:
http://www.apachelabs.org/apache-mbox/199902.mbox/[EMAIL PROTECTED]
Please note that the above is not a valid URL. Specifically, the
and characters are technically not
On Thu, Sep 20, 2001 at 12:53:39AM -0700, Alex Stewart wrote:
On a largely unrelated note, but something I found a little ironic given
the nature of this list:
Aaron Bannert wrote:
http://www.apachelabs.org/apache-mbox/199902.mbox/[EMAIL PROTECTED]
Please note that the above is not
On Wed, Sep 19, 2001 at 06:34:11AM -, [EMAIL PROTECTED] wrote:
jwoolley01/09/18 23:34:11
Modified:server/mpm/worker worker.c
Log:
I was kinda hoping those (void)some_function() and (request_rec *)NULL
casts would go away before this committed, but alas I didn't say
On Wed, Sep 19, 2001 at 06:34:11AM -, [EMAIL PROTECTED] wrote:
jwoolley01/09/18 23:34:11
Modified:server/mpm/worker worker.c
Log:
I was kinda hoping those (void)some_function() and (request_rec *)NULL
casts would go away before this committed, but alas I didn't say
1 - 100 of 117 matches
Mail list logo
