From dev-return-3569-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Jul 24 17:36:04 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 81517 invoked by uid 500); 24 Jul 2001 17:36:03 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 81505 invoked from network); 24 Jul 2001 17:36:03 -0000 Date: Tue, 24 Jul 2001 10:35:40 -0700 From: Aaron Bannert To: Justin Erenkrantz Cc: new-httpd@apache.org, dev@apr.apache.org Subject: Re: [PATH] MPMT single acceptor patch Message-ID: <20010724103540.K28176@ebuilt.com> References: <01072408445202.03564@koj.rkbloom.net> <20010724090806.L26972@ebuilt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724090806.L26972@ebuilt.com>; from jerenkrantz@ebuilt.com on Tue, Jul 24, 2001 at 09:08:06AM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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