Re: [TCLCORE] Inconsistent buffered I/O

[Tom J. <tom...@gm...>]

I know I'm not the best at expressing myself, but I'm not wasting my
time spouting off theory.

Instead of guessing at the extent of the "bug" I did actual tests. The
original bug report contained a file with three chars and did one
cycle of read/write.

My testing showed that there are many more variables involved, the
buffer size (even if -buffering is set to none), flushing/seeking
prior to each puts/read. And results depend on more than  one cycle of
read/puts.

So I know in advance that the proposed solutions will not work.

What will work, if it is possible, a solution which will not affect
any working code (but will impact performance for all channel
commands) will do the following:

Establish a two bit of history for each fd. 10 indicates safe for
reading, 01 indicates safe for writing and 11 indicates safe for both
(typical initial condition, or after flush/seek/etc.)

If such a history, or an equivalent cannot be established, then it is
guaranteed that you will change the operation of the channel code so
that buffering will not exist.

One of the proposed solutions (2a) is a flush prior to read. This
applies to every read? If not, how do you figure out when to apply it?
(Using a history avoids this overhead.)

But the problem is that my testing clearly shows that you must also do
something prior to a write, if you previously did a read (and no
intervening seek or flush).

So following the 2a solution, a seek (which includes a flush) or a
flush is required prior to any read or write/puts.

This situation would appear to be equivalent to no buffering. But in
Tcl it isn't.

With no buffering (-buffering none) but without the seek/flush prior
to each read/puts, you will get unexpected results (you must also set
a -buffersize to get correct results).

The solution (seek/flush prior to any read/puts) will solve the
current "bug", but it will result in poor performance and behavior
changes.

Performance: this is the reason we use buffers.

Maybe ask yourself: do you really think you have discovered a 20 year
old bug, a bug so severe that nobody could possibly be using code
which reads and writes without intervening seek/flush?

Really? You found a 20 year old serious bug?

My experience suggests that you pay a price for everything. You want
consistency between buffered read and write? It will cost you. Telling
you guys you don't know what you are doing? Yes it will cost me. You
can have a cheerleading pep talk if you want. Pump yourselves up if
you want. But you are not going to discover some magic and free way to
get around this.

Scientist require lots of proof to overturn long believed theories. If
code has held up for 20 years, I think the proof should be a little
more than a three char file. I've already proved this is an incomplete
picture.

BTW, the problem also infects w+, assuming it is a problem.

Did anyone besides me check that? No.

If the problem took 20 years to identify, the first step should be
establishing expected results for every combination of options.
Otherwise the fix may break something else. Nobody is affected by the
current "bug", somebody may be affected by the fix.

If I have breached the decorum of this list, sorry.

Just remember, you propose to change the way tcl works. The way tcl
works is important to me, maybe you don't like the way it works. Most
people like it, nobody has complained about this particular issue in
20 years. The silence is deafening.

Ever heard of the story of Chicken Little? The sky is falling?
Chickens! The sky is not falling. If the sky was falling, someone else
would have noticed by now. Or maybe the original tclers were just a
bunch of dumb-shits, and all the users for the last 20 years, total
morons. Or maybe they figured out what I figured out with a few hours
of research? Twenty years worth of code, twenty years worth of users
and nobody noticed such a trivial bug...one which can be demonstrated
with a three char long file.

Somehow 20 years worth of tclers never got it right, never even
noticed it was wrong! According to this group. This represents either
an extreme amount of hubris or an extremely low opinion of the
programming skills of everyone else.

I admit I never noticed, but for good reason: I never open a file for
reading and writing. But it didn't take me too long to come up with a
solution. I guess I'm an idiot for figuring out something which is
guaranteed to work and never impact anyone else who uses read/puts.
That is what I call doing it right. I don't believe in babysitting
novice programmers.

tom jackson

The hardest bug to find is one which doesn't exist.




On Thu, Nov 26, 2009 at 8:17 AM, Kevin Kenny <kev...@gm...> wrote:
> Donal K. Fellows wrote:
>>
>> In short: Damnit! We're Tclers! We'll do this _Right_!
>
> Preach it, brother!