Jim Jagielski [EMAIL PROTECTED] writes:
Greg Ames wrote:
Greg Ames wrote:
Non-graceful restarts in threaded had the same problem worker has today:
no way to blow away threads which are serving long-running requests.
Actually, an Apache'r who wishes to remain anonymous had a
Jim Jagielski wrote:
Greg Ames wrote:
Non-graceful restarts
in threaded had the same problem worker has today:
no way to blow away threads which are serving long-running requests.
Actually, an Apache'r who wishes to remain anonymous had a
On Friday 30 November 2001 06:46 am, Greg Ames wrote:
Jim Jagielski wrote:
Greg Ames wrote:
Non-graceful restarts
in threaded had the same problem worker has
today: no way to blow away threads which are serving long-running
requests.
Greg Ames wrote:
When did I say graceful? This idea is for non-graceful restarts.
Today they aren't much different than graceful restarts, AFAIK.
My bad... I totally missed the 'non-' part... not enough coffee,
or maybe too much :) :)
--
On Thursday 29 November 2001 09:20 am, Brian Pane wrote:
From a performance perspective, the two limitations that I see in
the current worker implementation are:
* We're basically guaranteed to have to do an extra context switch on
each connection, in order to pass the connection from
On Thu, 29 Nov 2001, Brian Pane wrote:
Weren't the thread management problems with the threaded MPM
related specifically to shutdown? If it's just shutdown that's
a problem, it may be possible to solve it.
Graceful restart was the big problem.
--Cliff
Aaron Bannert wrote:
On Thu, Nov 29, 2001 at 09:20:48AM -0800, Brian Pane wrote:
From a performance perspective, the two limitations that I see in
the current worker implementation are:
* We're basically guaranteed to have to do an extra context switch on
each connection, in order to pass
On Thu, Nov 29, 2001 at 09:31:01AM -0800, Ryan Bloom wrote:
On Thursday 29 November 2001 09:20 am, Brian Pane wrote:
So...please forgive me if this has already been considered and dismissed
a long time ago, but...why can't the listener and worker be the same
thread?
That's where we were
On Thursday 29 November 2001 09:48 am, Aaron Bannert wrote:
On Thu, Nov 29, 2001 at 09:31:01AM -0800, Ryan Bloom wrote:
On Thursday 29 November 2001 09:20 am, Brian Pane wrote:
So...please forgive me if this has already been considered and
dismissed a long time ago, but...why can't the
On Thursday 29 November 2001 09:41 am, Brian Pane wrote:
Ryan Bloom wrote:
On Thursday 29 November 2001 09:20 am, Brian Pane wrote:
From a performance perspective, the two limitations that I see in
the current worker implementation are:
* We're basically guaranteed to have to do an extra
On Thursday 29 November 2001 09:45 am, Brian Pane wrote:
Aaron Bannert wrote:
On Thu, Nov 29, 2001 at 09:20:48AM -0800, Brian Pane wrote:
From a performance perspective, the two limitations that I see in
the current worker implementation are:
* We're basically guaranteed to have to do an
Ryan Bloom wrote:
The model that Brian posted is exactly what we used to do with threaded,
if you had multiple ports.
No, you're missing a key difference. There's no intra-process mutex in
Brian's MPM.
One thread at a time is chosen to be the accept thread without using a
mutex. Once
On Thu, Nov 29, 2001 at 09:59:10AM -0800, Ryan Bloom wrote:
On Thursday 29 November 2001 09:45 am, Brian Pane wrote:
Right--the fact that the transaction pools are children of a pool
owned by the listener thread means that we have to do locking when
we destroy a transaction pool (to avoid
Brian Pane wrote:
From a performance perspective, the two limitations that I see in
the current worker implementation are:
* We're basically guaranteed to have to do an extra context switch on
each connection, in order to pass the connection from the listener
thread to a worker
14 matches
Mail list logo
