etc.curl: Formal review begin

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Aug 30 15:11:51 PDT 2011


On 8/30/11 4:11 PM, Marco Leise wrote:
> Am 30.08.2011, 21:56 Uhr, schrieb Walter Bright
> <newshound2 at 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



More information about the Digitalmars-d mailing list