On 8/30/11 4:11 PM, Marco Leise wrote:
Am 30.08.2011, 21:56 Uhr, schrieb Walter Bright
<newshou...@digitalmars.com>:
On 8/30/2011 11:59 AM, Andrei Alexandrescu wrote:
Unless the OS issues speculative reads (which I don't think it does
for either
files or sockets), any time spent in write() is a net loss for
reading speed.
Now *that* was speculative, if you know what I mean. Take a look at this
article on on-demand readahead: http://lwn.net/Articles/235164/
I suspect the situation on other operating-systems is similar.
The buffer for Linux pipes is currently maxed at 64 KB, so there is some
room for multiprocessing as well.
Sockets are different, but as someone else already pointed out, the OS
has to handle the incoming traffic somehow, and it does so by filling a
receive buffer. The socket implementation in current operating systems
allows you to set the buffer size to large values. The network protocol
practically enforces asynchronous operations in the background.
Now, if write is buffered and the buffers are flushed asynchronously,
calls to
write() would be instantaneous. I'm not sure to what extent the major
OSs do
that, and for what types of files.
Both OSs and disk drives have write caches.
That's not the question. The question is whether the caches are flushed
asynchronously and under what regime. What I can say as an end user of
fwrite() et al is that such calls do take time - it's not
near-instantaneous.
Andrei
