Re: [Caml-list] Asynchronous IO programming in OCaml

[Goswin von Brederlow <goswin-v-b@web.de>]

Jérémie Dimino <jeremie@dimino.org> writes:

> On Wed, Oct 27, 2010 at 03:43:37PM +0200, Goswin von Brederlow wrote:
>> But then you tune your benchmark to give you the result you want instead
>> of benchmarking what normaly happens.
>
> That's true for read or write. The point i wanted to make is that in the
> general case, i.e. for a system call that blocks, wrapping it into a
> thread might not be a good solution because it degrades performances too
> much.

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. :)

>> And don't forget. Multi core systems are more and more widely
>> spread. What is wrong with 2 cores doing memcpy twice as fast?
>
> I don't think you can read or write in parallel the RAM with current
> architectures, but i may be wrong.

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).

>> Do you have a different solution for writes that will avoid threads when
>> a write won't block? And how do you restart jobs once the data has
>> actually been commited to disk? (i.e. how do you do fsync()?)
>
> Unfortunately no, we have no solution for write. The main problem i see
> with doing write in parallels with threads is to handle errors.
>
> Jérémie

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().

MfG
        Goswin