httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p...@netcraft.co.uk>
Subject Re: Replacement for mktemp and httpd_monitor
Date Fri, 29 Dec 1995 04:45:11 GMT
In reply to Jim Jagielski who said
> 
> Paul Richards wrote:
> > 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.
> 
> Feh... That's assuming that the heuristic is:
> 
>   1. Hard to code
>   2. Get's changed alot
> 
> #1 definately isn't true (the description is longer than the code) and
> #2 isn't true either. Why would we change the heuristic?? By provding the
> exact code that Apache uses, 3rd paryt apps are _assured_ OS independence.

No. That's assuming that instead of a fixed string there is a piece of
code generating these names. No matter how simple that piece of may be
the piece of code first has to be obtained from the Apache group before
a third party author can write code. That ain't exactly my idea of making
it easy on third party folks. There's one rather major flaw in your
assumption too, see my final comment below.

> > > > 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.
> 
> You pass the pointers whether they are malloced or whether they are
> statics.

Ok, talking about slightly different things here.  I was thinking
more about these huge strings we're creating on the stack, but that
wouldn't apply to the scoreboard filename since it's global.

> > Not in my opinion. I see no reason not to simply print out a fixed
> > string with the decimal pid appended to it.
> 
> Huh? That's exactly what's being done! Have you actually _looked_ at the
> diffs before commenting on them? Ohhh... the diffs use hex instead of
> decimal... Ok, easy change. Took 2 seconds... Next...

Yes, I did look at the diffs, in some detail. It's nothing at all like my
two lines (one to get the pid and one to print out a string). It's exactly
what it purports to be, a new, OS portable version of mktemp and I still
think it's unecessary and is only an issue because the original code
mistakenly used mktemp. These are not anonymous temporary files!

> > 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 scoreboard name isn't in the config files at all. It's hardcoded into
> apache.

Yes, but I think it should be a config option.

> Hello! The function doesn't have to be copied anywhere. It was "created"
> as a function to make things easier to understand and more modular. We

It does, it has to be copied into third party apps. The whole point was to
make it possible to develop third party apps independantly of Apache.

> can define a "standard" "temp" file for use by Apache. Right now, only 2
> such files are used: scoreboard and the lockfile, but more may happen.
> Are you honestly saying it's better to add the same exact lines of code
> many places in a distribution rather than making it a function and
> calling it? The added function allows for an OS-independant way of
> defining "temporary" filenames for use by (and for) Apache, instead of
> relying on such unknowns as 'mktemp'. The actual code used is simple,
> intuitive and very very unlikely to change. What's wrong with that?

Nothing per se but the problem was never that Apache needed some portable way
of generating temporary files with known names, it was that it was using
mktemp for a job it wasn't meant to do.

> 
> Let's go back aways and remember _why_ the patch was created: it was due
> to the fact that the actual scoreboard name varied from OS to OS, due to
> it being "named" by mktemp(). This made "3rd party apps", such as
> httpd_monitor, unable to be OS-independant since httpd_monitor _needed_
> to redo what mktemp() did. But there was no way for httpd_monitor to know
> how mktemp() did it's job. The solution was obvious: create our _own_
> version of mktemp that is simple, intuitive and does the job. Make the

But you're solving the wrong problem.

> call... Now where exactly is the major problem with the implementation?

The problem is that third party apps now have to include part of
the Apache src tree in order to read the scoreboard file.

Let's get back to the original problem, httpd_monitor wasn't portable
because it assumed a "standard" format for the scoreboard file when
in fact it wasn't because it used mktemp and mktemp isn't portable.
Now, how exactly does your patch help httpd_monitor, remember, it's a perl
script so you can't just drop in your function? Giving me the function
direct from the Apache sources isn't going to help my sh script or my
tcl/tk tool?

-- 
  Paul Richards, Netcraft Ltd.
  Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk
  Phone: 0370 462071 (Mobile), +44 1225 447500 (work)

Mime
View raw message