3 ms·
This is wrong. Looking for write syscalls is not a valid way to figure out where buffering is happening. Write by default is famously buffered in Linux, and s
by fooker 3y ago
This is wrong.
Looking for write syscalls is not a valid way to figure out where buffering is happening.
Write by default is famously buffered in Linux, and stdio/iostresm functions map closely to it. So, if you call these C functions N times, you'll see write being called N times.
Flushing calls fsync or some ioctl depending on the file descriptor is, iirc.
- deleted 3y ago[deleted]
- dundarious 3y agofflush and std::endl/std::flush are not synonymous with the fsync syscall. None of the standard libraries I tested above call fsync at all when using those functions. They flush the accumulated memory "to the file" in the sense of making a write syscall (or equivalent, e.g., writev), and they do not attempt to enforce a flush to disk, that's just left to the OS. The "line buffering" in question is the C/C++ library accumulated memory, and the relevant kind of "unbuffering/flushing" is just write-like syscalls. I meant to reply much sooner, with more info from empirical tests. But now I'm happy to leave it at just the write stuff and the note about the meaning of stdio/iostream "flushing". I think you have an incorrect or esoteric understanding of what the "buffering" in question is, but it doesn't matter to me. My argument is about what syscalls happen, and I don't care if you disagree with the (I think, standard) descriptor/terminology I'm using.