httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Replacement for mktemp and httpd_monitor
Date Fri, 22 Dec 1995 13:16:07 GMT
Paul Richards wrote:
> In reply to Jim Jagielski who said
> > 
> There's some over-engineering taking place here and some decisions I
> don't like. I want to be able to see the assosciated process id at a glance
> and that's hard if it's in hex.

Easy to change.

> 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.

> 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.

> 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.

> 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.

Jim Jagielski  << >>   |           "Wind the frog!"
  **  jaguNET Access Services  **      |       - Woody (from Toy Story)
++       Email:      +++        Voice:  410-931-3157       ++
++      +++         Data: 410-931-7060        ++

View raw message