httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] worker.mpm
Date Mon, 24 Dec 2001 21:39:48 GMT
On Monday 24 December 2001 12:54 pm, Jeff Trawick wrote:
> Ryan Bloom <rbb@covalent.net> writes:
> 
> > On Sunday 23 December 2001 09:47 am, Jeff Trawick wrote:
> > > Ryan Bloom <rbb@covalent.net> writes:
> > > 
> > > > On Sunday 23 December 2001 06:05 am, David Reid wrote:
> > > > > While trying to build the worker MPM on beos, I found that as we
didn't
> > > > > need/want the _np clutter these small patches were neccesary.  I
can't
> > > > > see anything wrong with simply committing them, but I thought I'd
throw
> > > > > them up here for discussion.
> > > > 
> > > > I personally hate the np functions, because they are completely non-portable,
> > > > as their name implies.  We should either find some way to make them portable,
> > > > or remove them IMNSHO.
> > > 
> > > Give the function a different name (not ending in _np).
> > > Make all os-specific lock types (everything but DEFAULT) end in _NP.
> > 
> > Renaming the functions doesn't make it a portable set of functions.  
> 
> The function can be portable because APR_LOCK_DEFAULT can work
> anywhere.  Heck, the *normal* way to get a lock could have a required
> parameter which would normally be APR_LOCK_DEFAULT.
> 
> This isn't so useless; instead, it can be used to avoid the ugliness
> that David encountered trying to get worker.c to build on a platform
> that only supports APR_LOCK_DEFAULT.
> 
> >                                                                      The fact
> > remains that anybody who uses those functions directly is writing incredibly
> > non-portable code.
> 
> The fact remains that Apache needs such a function.  The fact remains
> that APR has all the code available to supply what Apache needs.
> 
> Every time I "hear" that comment from you I worry for a moment (okay,
> a few minutes) that I'm going to wake up some day with Apache no
> longer be able to choose the lock implementation because you yanked
> the underlying mechanism and left no replacement.  -1 to that.

I agree that the function has uses, but I would prefer that it was implemented
in a more portable way.  The mechanism you suggested above is far more 
portable than what we have now, and I would be in favor or moving to that
model.  I am not about to rip out a function that we use, but the fact that
the function only works on some platforms, and in fact only makes sense
on some platforms makes me think that it can be implemented differently
so that it works everywhere.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message