On Wed, 12 Jun 2013 15:40:10 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 6/12/2013 11:36 AM, Steven Schveighoffer wrote:
If I understand correctly, the buffer is flushed, and ptr is reset to
the base,
the count is reset to 0. I don't see any code in there that does any
kind of
realignment.
You write 7 bytes, fflush. Now, every 4K buffered write from then on is
going to write from 7..4096+7, 4096+7..8192+7, ...
If this was such a big deal, then FILE * would guarantee the alignment
went back. It's not that hard.
That is one block or sector. The write cache of the OS or the drive
will
probably absorb this hit anyway.
Write caches are not always there.
The performance hit is extremely negligible.
Only if there is a write cache (which can be turned off, and are often
turned off for removable drives).
The write cache is irrelevant. The filesystem driver will dictate where
writes are done, and will likely cache.
And I have experience with turning them off -- some of my clients
requested that to avoid losing data that was in the write cache. It does
not all of a sudden slow down the performance of the drive.
Not only that, but the hardware can differ from file system to file
system. You are going through the file
system driver, through the disk driver, through the disk. All of those
pieces
are written to optimize writes that SPECIFIC hardware. There isn't
much you can
do to make this perform poorly.
Embedded systems and custom devices often do not have sophisticated
hardware or software drivers.
The day that D runs on an embedded system, with no drivers or OS, BUT
provides a C runtime that D builds on, is the day I'll agree with you ;)
But this whole discussion is academic at this point, Jérôme identified
that we can simply check to see if the file descriptor is valid, without
flushing.
I didn't say it was. See my other reply. In any case, if fflush is not
called on subsequent writelns, it is still possible to have the first
writeln succeed, the subsequent writelns fail and have main() return
success.
This isn't the problem that was presented. The problem that was presented
is that given an invalid file descriptor, writeln happily works (as long
as you don't cause a flush) and does not throw. This is unintuitive to
someone who is expecting writeln to choke on an invalid descriptor.
Subsequent writelns that fail throw an exception. Any writeln that causes
a flush will create an exception.
The rare corner case the "throw at end" will catch in addition is when the
file descriptor becomes invalid on the final flush only.
I think we can probably implement both checks. The 'throw at end' method
will catch both, but it would be nice to catch an invalid descriptor at
the call the causes the problem, not at the end when the program is mostly
gone. It's like catching a memory error far away from the cause.
-Steve
