apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATH] MPMT single acceptor patch
Date Tue, 24 Jul 2001 17:35:40 GMT
On Tue, Jul 24, 2001 at 09:08:06AM -0700, Justin Erenkrantz wrote:
> On Tue, Jul 24, 2001 at 08:44:52AM -0700, Ryan Bloom wrote:
> > This patch uses the original fdqueue.[ch] logic to implement the single acceptor,
multiple
> > worker logic in the threaded MPM.  The original fdqueue logic can be found in apache-apr,
but
> > I have attached a copy to this message.
> 
> Should we APRize the fdqueue.[ch] code and stick it in apr-util?  It
> may be a little lightweight to merit that though.  However, it also 
> relies on pthread condition variables.  Maybe now would be a good 
> time to add condition variables to APR?  Do other platforms have
> the concept of condition variables?
> 
> (I know Aaron would love to see condition variables in APR.)  -- justin

Of course I'd love to see condition variables in APR, and I think it
applies perfectly to this use case in httpd's threaded mpm, like this:

- start up a pool(*) of worker threads 
- use rbb's listener thread to generate events by:
  - poll()ing for POD events or connect()s on the socket
  - POD events would be broadcast to all [sleeping] threads so they
    could wake up and die.
  - connect events could signal a single thread to wake up and handle the
    request.

(* not to be confused with a memory allocator/scope pool)

Later we could add more fanciness by adding another thread to monitor the
number of threads waiting in the threadpool, and increase or decrease that
number as necessary to meet load)



I'm really only familiar with the posix concept of conditions, so I really
have no idea if we could map this functionality onto other systems like
OS2/Win32. To get the discussion going, here are the things we'd need to
support (if we decide to shadow POSIX):

- cond_wait(cond, mutex)
  wait for a condition to occur on 'cond'. 'mutex' is expected to be already
  locked, so cond_wait() must be able to atomically unlock 'mutex' and put
  the calling thread to sleep.

- cond_signal(cond)
  wakes up a thread that's waiting on 'cond'.

- cond_broadcast(cond)
  wakes up all threads waiting on 'cond'.

- cond_timedwait(cond, mutex, timespec)
  acts like cond_wait(), wakes up automatically when 'timespec' happens
  (it's an absolute time)
    [not sure if this one is necessary yet]

Will the experts on each non- or semi-POSIX system please comment on if
these concepts are implementable? At this point I'm ignoring issues like
PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply providing
"intraprocess" conditions would give us a huge benefit.

-aaron


Mime
View raw message