httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: Replacement for mktemp and httpd_monitor
Date Wed, 27 Dec 1995 23:57:28 GMT
In reply to Jim Jagielski who said
> Paul Richards wrote:
> > http_monitor has to have the same mkatemp as
> > Apache does, this isn't consistent with using a scoreboard name that
> > arbitrary third party tools can access.
> Ahh, but it _is_, since the scoreboard name can be totally defined by
> a few lines of code. Basically it's htaccess.PID, where PID is a 0 filled
> number. I used hex because that meant that it can be limited to only 8
> chars instead of the 10 or so decimal numbers. Unless we want to go with
> a scoreboard name that's totally static and unchangable, using explicit
> code instead of relying on functions whose implementation varies from OS
> to OS, is the way to go. This is what the patches do.

But, third party tools will have to share code with Apache to ensure
they are using the same heuristic for the creation of the filename. That's
not good because each time that code is changed in Apache all third party
authors have to upgrade their code too.

> > Strings should be malloced at run time, avoids problems with
> > fixed length buffers and reduces the executable image and generally make
> > better use of memory.
> I don't see that. mallocs are expensive. And fixed length buffers are only
> a problem when you allow arbitrary data. This diffs don't.

But these strings are only malloced *once* at startup. There's no
performance penalty, other than a slightly slower startup. I think
performance would actually be faster since you then pass pointers
on the stack instead of big strings.

> > Also makes security holes with sprintf a non-issue
> > because strings aren't on the stack.
> Again, since we limit things in the code, we can use sprintf. As I see
> it, the diffs avoid overflows by limiting the output width in the
> sprintf statement to be exactly the size required. There's nothing
> wrong with using sprintf if you can assure things are right, which is
> what is being done.
> > 	
> > 	sprintf(lock_fname, "%s.%8d", LOCK_FILE, pid);
> Isn't this what the diffs do anyplace, in a way? Only we use a function
> call, which is better since it assures those reading the code that there's
> a consistant way of doing it that's being used.

Not in my opinion. I see no reason not to simply print out a fixed
string with the decimal pid appended to it. The string can be
configurable so ti's path and/or name can be changed according to the
admins taste  but it would have a default which third party code 
writers can rely on. The config files are "standard" anyway so the actual
filename used can be easily determined just by reading it from
the config file and appending the pid.

The existence of a function call is the over-engineering I was referring 
to. there's nothing more consistent than a straight text string. A function
is not consistent if that function has to be copied in every program that
has to access that file. I don't see thatthe added function buys us
anything except added complexity.

> > Why is there a need for a lock file? It looks to me like there's a file
> > being created which then has fcntl applied to it as a locking mechanism.
> > If fcntl works across platforms and is used in this manner, why not lock
> > the scoreboard file itself. If fcntl isn't portable (I'm not sure it
> > is actually) then the simple existence of the lock file is enough for
> > locking and fcntl on it is redundant. fcntl is likely better performance
> > wise than creating and deleting the lock file though so I'd accept it
> > on that basis if it truly is portable.
> I'll let others handle this, but I seem to recall that on some platforms,
> without this "management", Apache would crash and burn. A/UX, my
> platform, doesn't require this and, in fact, using it involves a big
> performance hit.

I remember that thread vaguely but wasn't paying much attention at the
time. Someone want to remind me?

  Paul Richards, Netcraft Ltd.
  Phone: 0370 462071 (Mobile), +44 1225 447500 (work)

View raw message