httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: patch list vote
Date Wed, 15 Mar 1995 17:22:18 GMT
[BTW, folks, my own ballot in Rob's format will follow shortly].

   From: Rob Hartill <hartill@ooo.lanl.gov>
   Date: Wed, 15 Mar 95 14:16:00 MST

   > 
   >    B17: raise queue size in listen()
   >    vote: -1   (there are kernel issues here, I have no argument with
   > 		the patch, but I'd like to see it more portable first)
   > 
   > I'm also not sure I understand the objection --- could you be a little
   > more specific about which "kernel issues" are posed by:

   Like I said, I have no problem with this, I just want to
   raise the issue of recompiling the sunos kernel to make it
   effective.

As the only guy here cursed with SunOS, I'm not quite sure I
appreciate the favor ;-).

   I think it's a mistake to just change the 5 to a
   128 then forget it.

I think this is the sort of cleanup issue which Cliff is trying to
address as part of his integration process.

   We at least need to make it obvious in
   the code and/or documentation that the kernel might thump the
   128 in favour of a much lower 5, along with instructions
   on how to make the kernel change. Do that and I'll be happy.

Good point, but I see this as a doc issue --- we may want a page
someplace with a lot of generic advice on how to run a high
performance server (use local disks if you possibly can, configure the
kernel as a file server, use -DMINIMAL_DNS to cut off the name server
if you can afford it, likewise for AllowOverride None to ditch
.htaccess files); configuring the kernel TCP parameters would belong
there as well.  A comment in the code would be nice as well, but I
don't think it's the first place J. Random Sysadmin is likely to turn
for advice if their system is hit with the problem.

   >    P12: Shared-memory name server cache
   >    vote: -1   (couldn't compile it on HP-UX)
   > 
   > (NB, it could be made to compile on HP-UX fairly easily --- just
   > replace "flock (..., LOCK_SH)" with "fcntl (..., F_SETLKW, ...)" with
   > appropriately initialized struct flock's as the third args).

   When this is implemented, I'll remove my veto.
   Also, I think the default should be to have this switched off.

Agreed about the default --- like I keep on saying, apache_pre is not
my idea of what a real release should look like.

   As a rule I will veto non-protable code, until persuaded 
   otherwise.

Unfortunately, shared memory is not likely to be completely portable.

   >    E15: add new CGI variables
   >    vote: -1   (need to discuss consequences on CGI spec)
   > 
   > It's a nonstandard extension which doesn't affect any script which
   > adheres to the letter of the spec.  Do you think that's a bad idea?

   Can we first talk to whoever is responsible for the CGI spec
   (is anyone ?) - we might need to rename the variables and they
   might have some new ones that we could add too.
   The danger here is assuming things will be accepted only to
   find that they are, but in a slightly different format - we
   then have to support both :-(   - that mistake was made with
   Netscape <CENTER> - I haven't looked, but I bet they still support
   it even though it is redundant and bad HTML.

   If nobody is responsible for CGI, we can just make the new
   variables and post something to say "this is CGI/1.2" - who's going
   to argue ?  :-)

As a general rule, this is a serious concern, but somehow I don't see
a variable called DOCUMENT_ROOT being anything other than what Brian's
code sets it to ;-).

   One thing I'd like to see in cgi is a way for a cgi script to
   tell/ask the server not to kill the process for any reason - so that
   a script can start background tasks which won't be killed by
   the server after some timeout.

Does it not work for the script to simply fork off a child process?
(It looks to me like it should --- kill_children() uses kill(), and
not killpg()). 

   rob

rst


Mime
View raw message