You've been worked over pretty thoroughly already, but anyway...
Sam <[EMAIL PROTECTED]> wrote:
> On Thu, 24 Feb 2000, Len Budney wrote:
>
> > However, they have about the similar wall-clock runtime as each other
> > and as /bin/cat. The best expectable speedup would be a factor of
> > about 2, not 1,000,000.
[Completely bogus straw-man code snipped]
> Both of these have "similar wall-clock runtime" too.
1. In my benchmark, I ganged 1,390 runs using actual, distinct email
messages as input. Thus I didn't see 00.00elapsed, and didn't think
to myself, ``Gee, buffered writes take no time at all!''
2. I benchmarked _safecat_, not some sort of bogus loop which doesn't
do anything. Why didn't you, since we were talking about safecat?
3. If you're making claims for putc(), why didn't your non-safecat program
_use_ putc? Why did you need to ``emulate putc()'s implementation
as closely as possible''? If you really did need to, why were you so
dismally incapable of it?
> Still, one version doesn't even register -- executes in less than a clock
> tick.
Amazing! You've discovered how to do useful work in zero time!
> Now, multiply that by hundreds of thousands of messages per second.
True; writing 100,000 messages in 0 seconds is mighty fast! You _are_
a guru!
> > HP/UX, for example, they are (were) written so poorly that returns
> > from a signal handler dropped back inside the macro.
>
> Anyone who has two brain cells to rub together knows enough not to
> mix stdio and signal handling together. stdio is not guaranteed to
> work at all in conjunction with signal handling.
Thanks for the tip! That might have something to do with why I didn't
use stdio. (``grep sigaction *.c'')
> > How do I know why putc() fails when it fails?
>
> Check errno. Always works for me.
This is guaranteed on which platforms? Broken on which? Which standard
requires the use of errno? Why don't the manpages say so? Finally, how
did you verify that it ``always works'' for you?
> I recall that the original excuse for this absurd logic was that it's
> too gosh darn difficult to properly check the return value from a
> multicharacter write() call.
Wrong again. It's true I don't see the point in implementing something
whose need is not established. ``Profile, don't speculate.'' By the way,
try ``man 2 write''. Suggesting I can't handle return codes, when you
can't even supply correct arguments, is hilarious.
Thanks anyway.
Len.
--
There is no dispute that the proposed code fails in exactly the situations
that I said. There are simply religious claims that I shouldn't care
about that type of breakage.
-- Dan Bernstein
