You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <st...@raleigh.ibm.com> on 2000/02/23 16:46:35 UTC
Re: need ap_initialize() before create_process()->...->lock_inter()->semop()
> Basically, ap_initialize() needs to get called before create_process(),
> since create_process() passes op_on structure to semop() to get a lock,
but
> op_on isn't initialized until ap_initialize() calls setup_lock(). Here is
> a slight rearrangement to main() which calls ap_initialize() earlier...
>
Just committed this patch. A couple of suggestions... Most folks on the
list prefer unified diffs (diff -u ). They are easier to read. Also, notice
the patch you posted has line wraps in it. Not good for patches, if you want
them to apply :-). I (and a few other folks on the list) have had mixed
success posting patches with Lotus Notes. FYI...
Bill
patch submission format
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 04:21 PM 02/24/2000 -0600, you wrote:
>On Thu, Feb 24, 2000 at 12:46:44PM -0600, William A. Rowe, Jr. wrote:
> > would you update http://dev.apache.org/patches.html to
> > reflect this? I know we would all already be complying
> > if we weren't originally mislead.
>
>One reason that the page hasn't been changed yet is that unified diffs
>aren't available on all platforms. And trying to ask for unified diffs
>for some people and context diffs for the rest might get confusing.
>But you're right, we probably ought to note that somehow.
"We prefer that patches be submitted in unified diff format:
diff -u file-old.c file.c
but that isn't available on all platforms. If your platform doesn't
support unified diffs, please use a context diff instead:
diff -C3 file-old.c file.c
where file.c is the file affected. We should be able to feed the patch
directly into the "patch" program and have it update the file or set of
files. The -C3 is very important - line numbers can change on a daily basis
in some code files, so having context is crucial to knowing where it all
really goes."
Re: need ap_initialize() before create_process()->...->lock_inter()->semop()
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Feb 24, 2000 at 12:46:44PM -0600, William A. Rowe, Jr. wrote:
> would you update http://dev.apache.org/patches.html to
> reflect this? I know we would all already be complying
> if we weren't originally mislead.
One reason that the page hasn't been changed yet is that unified diffs
aren't available on all platforms. And trying to ask for unified diffs
for some people and context diffs for the rest might get confusing.
But you're right, we probably ought to note that somehow.
Re: need ap_initialize() before create_process()->...->lock_inter()->semop()
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> IMHO, the ap_initialize() problem is the dependencies between various
> initialization procedures. At a glance, ap_initialize is not only
> suppose to do the lock related setup, but also some other in other
> platforms, which might need to be called after some initializations like
> create_process, etc. (or in the future, just guess, may need ap_alloc_init
> first somehow)
>
> I would suggest:
> 1. Clarify what kind of initialization will ap_initialize() do
ap_initialize() is used to initialize APR. Anything APR needs initialized
(like the locks) is done here.
> 2. Make each component as self-initialized as possible.
APR is very self contained. The problem was that Apache started using APR
before APR was initialized. Jeff's patch should fix that.
Bill
Re: need ap_initialize() before create_process()->...->lock_inter()->semop()
Posted by rb...@apache.org.
On Thu, 24 Feb 2000, Chia-liang Kao wrote:
> IMHO, the ap_initialize() problem is the dependencies between various
> initialization procedures. At a glance, ap_initialize is not only
> suppose to do the lock related setup, but also some other in other
> platforms, which might need to be called after some initializations like
> create_process, etc. (or in the future, just guess, may need ap_alloc_init
> first somehow)
>
> I would suggest:
> 1. Clarify what kind of initialization will ap_initialize() do
> 2. Make each component as self-initialized as possible.
ap_initialize does all setup for APR. It should always be the first
function called in an APR program.
If you can garauntee that any structure is them same on different
platforms, then we can make most APR componenets self-initialized on Unix
platforms, but that doesn't help with other platforms.
Platforms like Windows use run-time function calls to determine what their
environment is like. ap_initialize puts all of those calls in one place
for each platform. Somewhere in the Windows code, we should be making
sure Win32 networking is installed, this should be done in ap_initialize
(it isn't currently, but that's because ap_initialize wasn't around when
the code was initially written).
ap_initialize is going to have a separate function call for each APR
component. I haven't gotten around to doing this yet though.
Ryan
>
> For example, if sembuf and struct flock is always in that order in
> all platform, we could just statically fill op_on/op_off/lock_it/unlock_it
> and elimate setup_lock().
>
> On Wed, Feb 23, 2000 at 10:46:35AM -0500, Bill Stoddard wrote:
> > > Basically, ap_initialize() needs to get called before create_process(),
> > > since create_process() passes op_on structure to semop() to get a lock,
> > but
> > > op_on isn't initialized until ap_initialize() calls setup_lock(). Here is
> > > a slight rearrangement to main() which calls ap_initialize() earlier...
> > >
> > Just committed this patch. A couple of suggestions... Most folks on the
> > list prefer unified diffs (diff -u ). They are easier to read. Also, notice
> > the patch you posted has line wraps in it. Not good for patches, if you want
> > them to apply :-). I (and a few other folks on the list) have had mixed
> > success posting patches with Lotus Notes. FYI...
>
Come to the first official Apache Software Foundation
Conference!!! <http://ApacheCon.Com/>
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
2121 Stonehenge Dr. Apt #3
Raleigh, NC 27615 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------
Re: need ap_initialize() before create_process()->...->lock_inter()->semop()
Posted by Chia-liang Kao <cl...@CirX.ORG>.
IMHO, the ap_initialize() problem is the dependencies between various
initialization procedures. At a glance, ap_initialize is not only
suppose to do the lock related setup, but also some other in other
platforms, which might need to be called after some initializations like
create_process, etc. (or in the future, just guess, may need ap_alloc_init
first somehow)
I would suggest:
1. Clarify what kind of initialization will ap_initialize() do
2. Make each component as self-initialized as possible.
For example, if sembuf and struct flock is always in that order in
all platform, we could just statically fill op_on/op_off/lock_it/unlock_it
and elimate setup_lock().
On Wed, Feb 23, 2000 at 10:46:35AM -0500, Bill Stoddard wrote:
> > Basically, ap_initialize() needs to get called before create_process(),
> > since create_process() passes op_on structure to semop() to get a lock,
> but
> > op_on isn't initialized until ap_initialize() calls setup_lock(). Here is
> > a slight rearrangement to main() which calls ap_initialize() earlier...
> >
> Just committed this patch. A couple of suggestions... Most folks on the
> list prefer unified diffs (diff -u ). They are easier to read. Also, notice
> the patch you posted has line wraps in it. Not good for patches, if you want
> them to apply :-). I (and a few other folks on the list) have had mixed
> success posting patches with Lotus Notes. FYI...
RE: need ap_initialize() before create_process()->...->lock_inter()->semop()
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Bill,
would you update http://dev.apache.org/patches.html to
reflect this? I know we would all already be complying
if we weren't originally mislead.
Bill
> Most folks on the
> list prefer unified diffs (diff -u ). They are easier to
> read. Also, notice
> the patch you posted has line wraps in it. Not good for
> patches, if you want
> them to apply :-).