Version française
Home     About     Download     Resources     Contact us    
Browse thread
Asynchronous IO programming in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jérémie Dimino <jeremie@d...>
Subject: Re: [Caml-list] Asynchronous IO programming in OCaml
On Thu, Oct 28, 2010 at 11:00:59AM +0200, Goswin von Brederlow wrote:
> Hehe, and you have prooven yourself wrong. As you said, when the file
> isn't cache and the syscall actually blocks there is no time
> difference. The reasons being that the blokcing takes the majority of
> time anyway and the context switch for the thread on the read doesn't
> cost anything since the kernel needs to context switch anyway. :)

The kernel will always prefetch a part of the file, so the first read
will launch a needed thread but not subsequent reads until the offset
reach a part of the file not yet cached.

And again, for other system calls, such as fstat, launching a thread is
not a good solution.

> NUMA has memory dedicated to each core. Each core can access its memory
> fast. Accessing some other cores memory on the other hand is slower (and
> will have to fight for access with that core).

And so that is a bad solution for Lwt since it runs on one system
thread.

> Nah, if you can detect the error then handing is easy. The problem is
> detecting. Write() itself can fail and that is easy to detect. But
> write() succeeding doesn't mean the data has been written
> successfully. You can still get an error after that which you only get
> on fsync().

Take for example buffered channels, when you would have to flush the
buffer, you would launch a thread calling write and let the program
continue to write onto the channel, assuming that the write succeed. But
if one write fails, you would get the error latter. And worst, if the
program stop using the buffer after the flush, it will never get the
error.

Jérémie