On Wed, 12 Jun 2013 08:26:43 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 6/11/13 10:07 PM, Steven Schveighoffer wrote:
>> On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2korden@gmail.com>
>> wrote:
>>> The best solution would be for writeln() to throw on use, and I think
>>> it's fairly easy to implement: just flush once after using the file
>>> descriptor for the first time, and throw if it fails.
>>
>> This is a good idea.
>>
>> I think you meant "just flush once after using the FILE * for the first
>> time"
>>
>> -Steve
>
> Yah, but now we're looking at extra state associated with each file etc.

There is room.  Each File is allocated on the heap.

> Also it's kind of unexpected.

According to this whole conversation, it is expected :)

-Steve

On 6/12/13 11:18 AM, Steven Schveighoffer wrote:
> On Wed, 12 Jun 2013 02:48:44 -0400, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 6/11/2013 10:15 PM, deadalnix wrote:
>>> On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright wrote:
>>>> I don't agree. Buffering is often done on page size boundaries -
>>>> throwing out
>>>> a random number of characters and then flushing will get it all wonky.
>>>
>>> You clearly missed something in the discussion here. The proposal is
>>> to flush
>>> once at first use, so an Exception is thrown. Nothing change after
>>> that first
>>> flush at initialization, other flushes stay where they are.
>>
>> Not at all. A flush forces a write to the disk - that's the point of
>> it. Disks are not at all well tuned to writing a few bytes, they like
>> to be written in aligned blocks of block sizes, and the I/O subsystem
>> is designed for that.
>>
>> This is why stdout has a flag in it saying if it is a "block oriented"
>> or "character oriented" device. It makes a big difference. This
>> proposal attempts to treat a block device like a character device. It
>> will work, but it will perform poorly.
>
> No, it does perform well. You are still not understanding the proposal.

I agree performance is not a problem. But it's just weird behavior. We should flush stdout termination, anything else would have to be carefully justified - and this is not.

Andrei

On Wed, 12 Jun 2013 11:32:58 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> I agree performance is not a problem. But it's just weird behavior. We should flush stdout termination, anything else would have to be carefully justified - and this is not.

stdout is flushed on termination.  Your code just doesn't puke a stack trace if there is an issue after main exits.

-Steve

On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
> No, it does perform well.  You are still not understanding the proposal.

Yes, I understand your proposal quite well.

Your benchmark is seriously flawed. Most modern systems cache writes in memory, and have a delayed write to the media. This hides the problem.

Try writing to a floppy disk system with mem caching turned off.

On 6/12/2013 8:34 AM, Steven Schveighoffer wrote:
> On Wed, 12 Jun 2013 11:32:58 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> I agree performance is not a problem. But it's just weird behavior. We should
>> flush stdout termination, anything else would have to be carefully justified -
>> and this is not.
>
> stdout is flushed on termination.  Your code just doesn't puke a stack trace if
> there is an issue after main exits.

There is main(), and then there is _Dmain(). Take a look at druntime/src/rt/dmain2.d

On 6/12/2013 5:30 AM, Andrei Alexandrescu wrote:
> On 6/11/13 11:42 PM, Walter Bright wrote:
>>> I think you meant "just flush once after using the FILE * for the
>>> first time"
>>
>> I think it's a bad idea, it'll muck up the buffering (i.e. make it slower).
>>
>> The fix is when main() returns to do the flush there.
>
> I agree. One question is, should we flush all buffers upon termination?
> fflush(null) would do so.
> http://www.gnu.org/software/libc/manual/html_node/Flushing-Buffers.html

I haven't heard about the fflush(null) thing. That may be gnu-specific. I don't think that works on Windows.

But yes, all open files should be flushed on termination. It's what C's stdio does already.

On Wed, 12 Jun 2013 11:55:39 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
>> No, it does perform well.  You are still not understanding the proposal.
>
> Yes, I understand your proposal quite well.
>
> Your benchmark is seriously flawed. Most modern systems cache writes in memory, and have a delayed write to the media. This hides the problem.

Sorry, but this is just bunk.  One uneven flush does not mess up all future aligned writes.  I/O is not that fragile.

If you can demonstrate your theory, I will concede.  Until you do, don't expect any more responses, it's no use arguing when you don't understand the problem.

-Steve

On 6/12/2013 8:59 AM, Walter Bright wrote:
> I haven't heard about the fflush(null) thing. That may be gnu-specific. I don't
> think that works on Windows.

Followup: I have indeed heard about the fflush(null) thing, as it's in the fflush code I wrote several eons ago!

On 6/12/13 11:59 AM, Walter Bright wrote:
> On 6/12/2013 5:30 AM, Andrei Alexandrescu wrote:
>> On 6/11/13 11:42 PM, Walter Bright wrote:
>>>> I think you meant "just flush once after using the FILE * for the
>>>> first time"
>>>
>>> I think it's a bad idea, it'll muck up the buffering (i.e. make it
>>> slower).
>>>
>>> The fix is when main() returns to do the flush there.
>>
>> I agree. One question is, should we flush all buffers upon termination?
>> fflush(null) would do so.
>> http://www.gnu.org/software/libc/manual/html_node/Flushing-Buffers.html
>
> I haven't heard about the fflush(null) thing. That may be gnu-specific.
> I don't think that works on Windows.

It's quite an old standard feature albeit obscure, I found it and forgot about it a couple of times already. Works everywhere, see http://www.cplusplus.com/reference/cstdio/ferror/ and http://msdn.microsoft.com/en-us/library/9yky46tz(v=vs.80).aspx

> But yes, all open files should be flushed on termination. It's what C's
> stdio does already.

http://d.puremagic.com/issues/show_bug.cgi?id=10344


Andrei

On 6/12/13 12:02 PM, Steven Schveighoffer wrote:
> On Wed, 12 Jun 2013 11:55:39 -0400, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
>>> No, it does perform well. You are still not understanding the proposal.
>>
>> Yes, I understand your proposal quite well.
>>
>> Your benchmark is seriously flawed. Most modern systems cache writes
>> in memory, and have a delayed write to the media. This hides the problem.
>
> Sorry, but this is just bunk. One uneven flush does not mess up all
> future aligned writes. I/O is not that fragile.
>
> If you can demonstrate your theory, I will concede. Until you do, don't
> expect any more responses, it's no use arguing when you don't understand
> the problem.

You're right that calling fflush() only once upon the first call will not cause a performance problem. My argument is different - it's not a good thing to do.

Andrei