httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: Proposal: Get rid of most accept mutex calls on hybrid server.
Date Fri, 07 May 1999 22:20:29 GMT
This works reasonably on single cpu systems, or when you use kernel
threads... but if you're using user threads on multicpu systems... you
really want other processes to get a chance in there.

Actually, I suspect that we don't really want to interprocess lock at all
in the multithreaded server.  We use non-blocking listening sockets, and
pay the wake-all cost for the small number of processes (we're talking
like 8 processes, right?) 

Dean

On Fri, 7 May 1999, Manoj Kasichainula wrote:

> Here's an idea for getting rid of the fcntl calls in the current
> poll-accept model. Right now, the goop in the get_connection routine
> looks like (taking Linux as the example to simplify the discussion)
> 
> pthread lock
> fcntl lock
> select
> accept
> fcntl unlock
> pthread unlock
> return
> 
> It would be nice to skip the fcntls if we know that another thread in
> the same process will be handling the next connection.
> 
> So, here's a proposal for a way to avoid this. idle_thread_count and
> have_accept_lock are initialized to 0.
> 
> idle_thread_count++;
> pthread lock
> if (!have_accept_lock) {
>     fcntl lock
>     have_accept_lock = 1
> }
> select
> accept
> idle_thread_count--;
> if (idle_thread_count == 0) {
>     fcntl unlock
>     have_accept_lock = 0
> }
> pthread unlock
> return
> 
> This will require an extra pthread lock to be sure that the increment
> and decrement operations are atomic, but that's a lot cheaper than the
> fcntl lock.
> 
> This will eliminate use of the fcntl lock when we still have threads
> available in the current process to handle requests.
> 
> -- 
> Manoj Kasichainula - manojk@raleigh.ibm.com
> IBM, Apache Development
> 


Mime
View raw message