...confirm this?

Well, not quite confirm, but there are certainly pointers in a thread you could have found for yourself by using Super_Search.

See especially the replies by Chromatic (Re: Flushing the print buffers.) and ikegami (Re^3: Flushing the print buffers.). You may also wish to read Suffering from Buffering, as recommended by Tilly

And just as a matter of curiousity, what OS so generously gives you 30K + X simultaneously open file_handles?

And just as a matter of curiousity, what OS so generously gives you 30K + X simultaneously open file_handles?

Linux probably does. I've never actually tried it, but if I cat /proc/sys/fs/file-max, I get a number like 300,000. I'm assuming the usual lower limits are probably set by the shell on login... ulimit -n shows 1024 for me.

I imagine, after a certain point, having that many open file handles is counter productive, but I could be wrong.

-Paul

There are three buffering states:

• unbuffered
• block buffered: Writes when 4KB* is accumulated.
• line buffered: Writes when \n is encountered or 4KB* is accumulated.

If a handle is buffered, line buffering is always and only used when the file handle is connected to a terminal.

So, if you're writing to a file, \n won't flush. But if you're writing to STDOUT and it hasn't been redirected, \n will flush if buffering wasn't turned off.

You can turn on buffering using

use IO::Handle qw( );
FH->autoflush(0);
[download]

You can turn off buffering using

use IO::Handle qw( );
FH->autoflush(1);
[download]

You can flush manually using

use IO::Handle qw( );
FH->flush();
[download]

* — Well, I *think* the buffer size is 4KB.

Writing a "\n" to the disk does not force a flush. From perlvar:

STDOUT will typically be line buffered if output is to the terminal and block buffered otherwise.

In general everything you write to the disk is greedily buffered by the OS unless and until the OS runs out of buffer-cache, at which point everything slows to a crawl.