More from firends at Sun who have now looked at the code.
}
} I finally found the hidden directory and here are some comments.
}
} Excuse my ignorance ....but this is the first time I have looked at any
} httpd.c code with any interest so some it may have some history obvious to
} others but not me.
}
} httpd.c:
}
} mutex_lock_on(); /* MP systems will use this to lock around "accept"
*/
}
} On Solaris, you need to use it for single processors also and I suspect in
} all library based Socket interface implementations like Unixware etc.
} The reason is that accept() is not an atomic operation but just a call in
} the ABI and any other call to the same fd at the same time can cause
} unpredictable behaviour.
}
} accept() happens to atomic on non-SMP BSD systems because of the serilaizatio
n
} incidental to all entry points to the kernel.
}
} This MP-not-OK, single-process-OK theory of accept() semantics probably
} comes from what happens to be true of SGI SMP implmenation where accept()
} is a system call which *might* be either non-premptible or makes-sure/happens
-
} to-be-true that at its preemption points, state is consistent.
}
} You know that we will be re-implmenting Socket interface and at that time
} will explicitly implment this reentrant accept() semantics.
}
} What my suggestion at this time would be not call this a MP systems lock
} or even mutex_lock_on and mutex_lock_off primitives. If this is the only
} use so far, call them accept_serialization_lock_on or somthing like that.
} This lock has attributes of not protecting data (which is what mutexes
} usually do) but serializing a portion of code (which can also be done
} with regular mutexes). However mutexes are more commonly associated with
} threads and not multiple processes [. threads share the address space and
} can see the mutex, processes do not and therefore cannot ]. So for this
} techno-weenie reason, I would suggest no calling it a mutex. Otherwise
} someone clueless will try to link to a threads library and get the
} mutex primitives from there. Any other name like foo_serialization_lock
} might also do.
}
} A lock/flock around a /tmp file with pid+fd of listener in its name might
} be a suggested implementaion for this serialization.
} I suspect the guy who reported the problem had not implemented these
} mutexes at all since they seem to be no-ops in the stock Apache code.
}
} lock.h nit
} -----------
} Everything seems to happen twice here including the copyright notice.
} Did someone press the "paste" key twice ?
}
} Other comments
} --------------
} Perhaps I have been hacking OS interfaces too long :-) I was somewhat
} horrified to see files like stream.h and constants like MP_SYSTEM.
}
} Have you guys thought about making the code more disciplined with
} for example an ap_ prefix to all header files and data structure
} types. Basically all the things that OS interfaces do to make sure
} they reserve the name space. You guys are not doing OS interfaces but
} you are doing *multi-OS* source code so reserving a name space and
} sticking to it might be a good idea for that reason. Other reason
} is more discipline when too many different people develop code.
}
} Maybe the need to track NCSA code prevents you guys from fixing a lot
} of "unclean" stuff in the code.
}
} I finally found the hidden directory and here are some comments.
}
} Excuse my ignorance ....but this is the first time I have looked at any
} httpd.c code with any interest so some it may have some history obvious to
} others but not me.
}
} httpd.c:
}
} mutex_lock_on(); /* MP systems will use this to lock around "accept"
*/
}
} On Solaris, you need to use it for single processors also and I suspect in
} all library based Socket interface implementations like Unixware etc.
} The reason is that accept() is not an atomic operation but just a call in
} the ABI and any other call to the same fd at the same time can cause
} unpredictable behaviour.
}
} accept() happens to atomic on non-SMP BSD systems because of the serilaizatio
n
} incidental to all entry points to the kernel.
}
} This MP-not-OK, single-process-OK theory of accept() semantics probably
} comes from what happens to be true of SGI SMP implmenation where accept()
} is a system call which *might* be either non-premptible or makes-sure/happens
-
} to-be-true that at its preemption points, state is consistent.
}
} You know that we will be re-implmenting Socket interface and at that time
} will explicitly implment this reentrant accept() semantics.
}
} What my suggestion at this time would be not call this a MP systems lock
} or even mutex_lock_on and mutex_lock_off primitives. If this is the only
} use so far, call them accept_serialization_lock_on or somthing like that.
} This lock has attributes of not protecting data (which is what mutexes
} usually do) but serializing a portion of code (which can also be done
} with regular mutexes). However mutexes are more commonly associated with
} threads and not multiple processes [. threads share the address space and
} can see the mutex, processes do not and therefore cannot ]. So for this
} techno-weenie reason, I would suggest no calling it a mutex. Otherwise
} someone clueless will try to link to a threads library and get the
} mutex primitives from there. Any other name like foo_serialization_lock
} might also do.
}
} A lock/flock around a /tmp file with pid+fd of listener in its name might
} be a suggested implementaion for this serialization.
} I suspect the guy who reported the problem had not implemented these
} mutexes at all since they seem to be no-ops in the stock Apache code.
}
} lock.h nit
} -----------
} Everything seems to happen twice here including the copyright notice.
} Did someone press the "paste" key twice ?
}
} Other comments
} --------------
} Perhaps I have been hacking OS interfaces too long :-) I was somewhat
} horrified to see files like stream.h and constants like MP_SYSTEM.
}
} Have you guys thought about making the code more disciplined with
} for example an ap_ prefix to all header files and data structure
} types. Basically all the things that OS interfaces do to make sure
} they reserve the name space. You guys are not doing OS interfaces but
} you are doing *multi-OS* source code so reserving a name space and
} sticking to it might be a good idea for that reason. Other reason
} is more discipline when too many different people develop code.
}
} Maybe the need to track NCSA code prevents you guys from fixing a lot
} of "unclean" stuff in the code.