reddit discussion on replacing Python in 0install

Steven Schveighoffer schveiguy at yahoo.com
Thu Jun 13 06:24:01 PDT 2013


On Wed, 12 Jun 2013 15:40:10 -0400, Walter Bright  
<newshound2 at 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


More information about the Digitalmars-d mailing list