Re: Virtual Hosting and the FHS
On Sat, 14 Jul 2001 02:58, Craig Sanders wrote:
> > I would be interested in the motivations and arguments anyone on the
> > list has to contradict my opinion. I'm sure it looks like I'm trying
> > to start a flame war, but I just cannot understand why anyone would
> > wish to log to a database. Perhaps someone can enlighten me.
>
> no idea. i agree with you. web logs just aren't important enough to
> warrant the overhead of a database.
>
> storing a daily/weekly/monthly *summary* of a few hundred bytes to
> enable easy charting of growth over time may be worthwhile...but that
> can be done in the log-processing scripts.
But webalizer gives you the type of cool graphs that customers love. Also
webalizer gives some interesting statistics that you can use too.
> > into the mod_perl / php / etc. picture, though, I really have not
> > investigated Apache 2.0 extensively. To be honest threading makes me
> > afraid my good old tools won't work anymore, or they will work but
> > I'll have to live without the benefit of the new thread model.
>
> why should they break anything? threads are just fancy lightweight
> processes.
>
> unless your tools involve complicated hacks to the apache code itself,
> i doubt it will make any difference. all (or at least most) of the
> standard modules like mod_perl, php, etc will be ported to apache 2.0
> within a few months.
Most C programmers don't know how to write threading code. Of those who do
most don't know how to do it properly.
I say this after experience working in software development teams training C
programmers, after debugging various free and non-free programs that use
threads, and after dealing with stupid technical support people who make it
clear how useless the programmers they report to are.
Threads are not just like processes. One significant difference between
threads and processes is that all memory and all file descriptors are shared.
So after a thread is started the parent thread can't free any memory that the
child is likely to use, all memory areas that are to be written to must be
duplicated or locked. File handles can't be closed without great
consideration. Most correctly working fork() based code will fail when
converted to threads because of these issues. Some such code will have race
conditions subtle enough that they may not be fully debugged for years...
Another issue is that of debugging. In multi-threaded programs the primary
thread generally does little work. However when a SEGV condition occurs the
core dump is of the stack of the primary thread, and the cause of process
termination is listed as "signal 9". This makes vendors of commercial
software refuse to examine such core files (they say that the user did kill
-9).
I am in no hurry to convert production servers to Apache 2.0 unless I can
turn off all thread functionality. However I'll convert my laptop ASAP as I
like playing with new experimental things on it. ;)
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: