Took too long to respond. Oh well, no one else did either...
On Tue, Nov 26, 2002 at 01:14:10AM -0500, Glenn wrote:
On Mon, Nov 25, 2002 at 08:36:59PM -0800, Manoj Kasichainula wrote:
BTW, ISTR Ryan commenting a while back that cross-thread signalling
isn't reliable, and it scares me in
On Thu, Dec 12, 2002 at 12:39:17AM -0800, Manoj Kasichainula wrote:
...
Add a descriptor (pipe, socket, whatever) to the pollset and use
it to indicate the need to generate a new pollset. The thread that sends
info down this descriptor could be programmed to wait a short amount of
time
Juan Rivera wrote:
Brian,
Does your model assume that connections are short lived (HTTP)?
One problem with the current model is that if you implement, let's say
mod_socks, it holds a connection per thread.
Is that something your model addresses?
I'm looking into a pure async i/o model which
Title: RE: request for comments: multiple-connections-per-thread MPM design
Brian,
Does your model assume that connections are short lived (HTTP)?
One problem with the current model is that if you implement, let's say mod_socks, it holds a connection per thread.
Is that something your
On Sat, Nov 23, 2002 at 06:40:58PM -0800, Brian Pane wrote:
Here's an outline of my latest thinking on how to build a
multiple-connections-per-thread MPM for Apache 2.2. I'm
eager to hear feedback from others who have been researching
this topic.
You prodded me into finally writing up a
On Mon, Nov 25, 2002 at 07:12:43AM -0800, Brian Pane wrote:
On Mon, 2002-11-25 at 00:20, Manoj Kasichainula wrote:
I was actually wondering why the reader and writer were seperate
threads.
It was a combination of several factors that convinced me
to make them separate:
* Take advantage
On Mon, Nov 25, 2002 at 08:10:12AM -0800, Brian Pane wrote:
On Mon, 2002-11-25 at 00:02, Manoj Kasichainula wrote:
while (event = get_next_event())
add more spare threads if needed
event_processor = lookup_event_processor(event)
ticket = event_processor(event)
if (ticket)
On Mon, Nov 25, 2002 at 08:36:59PM -0800, Me at IO wrote:
I'm just guessing here, but I imagine most CPU effort wouldn't be
expended in the actual kernel-user transitions that are polls and
non-blocking I/O. And the meat of those operations could be handled by
other CPUs at the kernel level.
On Mon, Nov 25, 2002 at 08:36:59PM -0800, Manoj Kasichainula wrote:
On Mon, Nov 25, 2002 at 07:12:43AM -0800, Brian Pane wrote:
The real reason I don't like the mutex around the poll is that
it would add too much latency if we had to wait for the current
poll to complete before adding a new
