httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Duplicate code.
Date Fri, 19 Nov 1999 20:03:45 GMT

Would you like another example?

Every MPM has a section for ap_thread_mutex functions.  None of them are
used as near as I can tell.  We never once in ANY of the MPM's call
ap_thread_mutex_new.  The code is useless and it's duplicated.  

I think the reason we have this problem (and this is not blame), is that
Dean started the MPM tree, and didn't get a chance to finish it.  MPM's
should be tiny things.  They should implement VERY VERY little.  In fact,
most MPM's should be ONE file, IMHO.  We took what Dean gave us, and
rather than refine it and make it smaller and tighter and cleaner, we just
ran with it.  Great.  But now, we have to either clean it up, or watch it
just get bigger.


On Fri, 19 Nov 1999, Manoj Kasichainula wrote:

> On Fri, Nov 19, 1999 at 10:16:33AM -0500, Ryan Bloom wrote:
> > The scoreboard and accept locking code seem to be the biggest offenders,
> Ummm, as of Monday, the accept lock code is based on APR for the two
> threaded Unix MPMs. Prefork still needs work, but that shouldn't be
> too difficult.
> You're seeing duplicate messages, because that's what you're working
> on, but that's really the only significant accept lock piece
> duplicated between mpmt_pthread and dexter. I don't think it's worth
> the effort to create a common ap_lock_with_error_report call.
> And besides, I'm hoping to take cross-process locking out of dexter
> completely by taking advantage of non-blocking accept.
> The scoreboard code is somewhat duplicated, but it's doing somewhat
> different things in the various Unix MPMs. In prefork and
> mpmt_pthread, it contains all the old-style scoreboard code. Dexter
> doesn't use the old-style scoreboard at all, so it just has generic
> code to create a block of shared memory, and another chunk of code to
> use it to maintain connection status. I think it would be useful to do
> a similar split of the scoreboard code in the other MPMs, but the
> proper way to do this is to get shared memory code into APR.
> > The idea itself is wonderful, but our execution has MPM's implementing all
> > of the helper functions that used to be common code.  Why can't MPM's just
> > be responsible for spawning threads and creating processes, and mapping
> > requests to those execution primitives it sees fit.  Anything else is
> > superflous, and most likely common to at least two MPM's.
> The Unix MPMs already have piles of common code, see unixd. Sure, more
> stuff could be moved, but the low hanging fruit has been picked
> already. 
> And MPMs will soon have to manage event-based I/O at some point too.
> -- 
> Manoj Kasichainula - manojk at io dot com -

Ryan Bloom
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

View raw message