Re: Request for comments: leader/follower MPM design

2002-02-19 Thread Greg Ames
Brian Pane wrote: Thanks for catching that. In this particular design, I think we'll be safe because only the current listener thread is ever allowed to pop from the stack. yeah, that occurred to me driving home yesterday. If we can guarantee there is only one popper at a time, that

Re: Request for comments: leader/follower MPM design

2002-02-19 Thread Ian Holsman
Greg Ames wrote: Brian Pane wrote: Thanks for catching that. In this particular design, I think we'll be safe because only the current listener thread is ever allowed to pop from the stack. yeah, that occurred to me driving home yesterday. If we can guarantee there is only one popper

Re: Request for comments: leader/follower MPM design

2002-02-18 Thread Brian Pane
Greg Ames wrote: Brian Pane wrote: Relative to the current worker MPM design, the potential advantages of this new design are: * Better cache utilization, because the stack makes it more likely that a recently active thread will serve the next request * An implementation that uses

Request for comments: leader/follower MPM design

2002-02-17 Thread Brian Pane
Now that APR is beginning to support atomic compare-and-set (CAS) operations, I decided to revisit an old idea: use a leader/follower design to improve upon the efficiency of the worker MPM. The following writeup describes my current design idea. It's somewhat radical, particularly in the parts