Mailing List Archive

Yet *another* new Shambhala spin...
I'm calling this one 0.5.1; it's in the usual place,
ftp://ftp.ai.mit.edu/pub/users/rst/shambhala5.1.tar.Z.

Possible problem (which hit me in retrospect) --- this has code for
mutual exclusion around the accept(), based on fcntl() locks on the
error log (not flock()), though it's only #ifdef'ed in on systems
where I believe it to matter. On some systems, that means that if the
error log is located on another server, and is NFS-mounted, the remote
server's *notorious* lockf daemon will come into play; that may cost
performance. If the error log is local, there won't be any problem.

Aside from that, I think it's generally an improvement on, well, the
last thing.

Changes with 0.5.1: [Hopefully complete]

*) Generalized cleanup interface in alloc.c --- any function can be
registered with alloc.c as a cleanup for a resource pool;
tracking of files and file descriptors has been reimplemented in
terms of this interface, so I can give it some sort of a test.

*) More changes in alloc.c --- new cleanup_for_exec() function,
which tracks down and closes all file descriptors which have been
registered with the alloc.c machinery before the server exec()s a
child process for CGI or <!--#exec-->. CGI children now get
started with exactly three file descriptors open. Hopefully,
this cures the problem Rob H. was having with overly persistent
CGI connections.

*) Mutual exclusion around the accept() in child_main() --- this is
required on at least SGI, Solaris and Linux, and is #ifdef'ed in
by default on those systems only (-DFCNTL_SERIALIZED_ACCEPT).
This uses fcntl(F_SETLK,...) on the error log descriptor because
flock() on that descriptor won't work on systems which have BSD
flock() semantics, including (I think) Linux 1.3 and Solaris.

This does work on SunOS (when the server is idle, only one
process in the pool is waiting on accept()); it *ought* to work
on the other systems.

*) FreeBSD and BSDI portability tweaks from Chuck Murcko.

*) sizeof(*sa_client) bugfix from Rob Hartill.

*) pstrdup(..., NULL) returns NULL, pace Randy Terbush.

*) block_alarms() to avoid leaking the DBM* in dbm auth (this should
be unnecessary if I go to the revised timeout-handling scheme).

*) For NCSA bug-compatibility, set QUERY_STRING env var (to a null
string) even if none came in with the request.

*) CHANGES file added to distribution ;-).
Re: Yet *another* new Shambhala spin... [ In reply to ]
>From: rst@ai.mit.edu (Robert S. Thau)
>Date: Tue, 4 Jul 95 11:49:19 EDT

>...
> *) More changes in alloc.c --- new cleanup_for_exec() function,
> which tracks down and closes all file descriptors which have been
> registered with the alloc.c machinery before the server exec()s a
> child process for CGI or <!--#exec-->. CGI children now get
> started with exactly three file descriptors open. Hopefully,
> this cures the problem Rob H. was having with overly persistent
> CGI connections.

Why not mark the fd's as close-on-exec, so that the kernel closes them for
you? It should be more efficient.

> *) Mutual exclusion around the accept() in child_main() --- this is
> required on at least SGI, Solaris and Linux, and is #ifdef'ed in
> by default on those systems only (-DFCNTL_SERIALIZED_ACCEPT).
> This uses fcntl(F_SETLK,...) on the error log descriptor because
> flock() on that descriptor won't work on systems which have BSD
> flock() semantics, including (I think) Linux 1.3 and Solaris.

I don't like the lock being on the error log; this has the potential of
being global to the system (consider multiple servers, single error log), and
may be on an NFS server. Instead, create a file in /tmp, unlink it and
use that file descriptor.

> *) For NCSA bug-compatibility, set QUERY_STRING env var (to a null
> string) even if none came in with the request.

I don't think this is a bug; in my version of the CGI spec
(<URL:http://www.ast.cam.ac.uk/%7Edrtr/cgi.html>) an unset variable is
the same as a null string. The argument is that http://x/a and http://x/a?
are identical URLs; the '?' is a separator, and is not part of the query_string
or path. So it does not seem particularly useful to encode the presence or
absence of the '?' by setting or unsetting the QUERY_STRING variable.

David.