SPASTIC Member wrote:
>
> 127.0.0.1 is just another interface. All possible errors can happen.
> Imagine a server where the load is high enough that other processes don't
> get to run much... they write to localhost, expecting what's on the other
> end to get it, but the localhost interface buffers overflow.
I would expect them to do what any other interface does, i.e. block
until there is space.
> Or the misconfigured routed that brings down the route to 127.0.0.1, or
> routes it to Timbuktu.
What error will this cause, and what is the correct action to take when
you get that error?
> Or the novice sysadmin who decides to ifconfig [lo|l0|lo0] down.
Same question.
> (Yes, I've seen all of these situations happen. The second one, I can't
> remember why we figured that the UNIX didn't read it anyway, since it had
> an interface with the destination IP number, but it routed it before
> checking its local interface list.)
>
> Assertions only belong in debugging code, not production code. In
> production code, reliability/robustness is more important than 'proper
> coding'. Granted, gcache is fixed now, but in the event of an error, if
> I'd coded it, I would have logged the error and moved on -- not died the
> first time an I/O operation failed to return the expected number of bytes.
> ('robust' means 'fault-tolerant', among other things.)
In my book, robust means correct behaviour. I do not see how you can
improve robustness by tolerating things that can only occur if there is
a programming error. I only assert stuff I believe cannot possibly occur
except if there is a programming error. Of course, I could be wrong in
my beliefs, in which case I have a bug, which I will fix as soon as I'm
told about it, naturally.
Next people will be suggesting that ignoring all signals leads to more
robust code. Sheesh.
> My $0.02, if it's worth anything. But if that's the way you code
> Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
If you want to use a system where programming errors are "corrected" by
removing the assertions that reveal them, that is your choice, of
course.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
