Re: [Caml-list] Multicore runtime

[Jesper Louis Andersen <jesper.louis.andersen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Mon, Sep 8, 2014 at 12:05 PM, Stephen Dolan <stephen.dolan@cl.cam.ac.uk>
wrote:

> Generally, we're going to try to avoid blocking C calls and instead
> use select/poll/kqueue/epoll to handle blocking I/O. From the fiber's
> point of view, this looks like normal blocking I/O, except if a system
> call returns EWOULDBLOCK we'll switch to another fiber until the I/O
> is ready.
>

This doesn't work for a (portable) implementation of File I/O which is why
everyone else (Go, Erlang, Haskell, ...) either has a pool of threads for
handling these (Erlang), or they just create another thread for handling
it, up to a point (Go). Network I/O is simple however, since you can batch
those on a standard epoll/kqueue/poll/select loop.

The problem is that for file descriptors representing (kernel) file
objects, they never return EWOULDBLOCK since you can always write to them
(rather subtle semantics). But once you write to them, that thread is off
to kernelspace and you only get it back milliseconds later when the write
is complete. In the meantime that thread is placed in uninterruptible
sleep. The async File I/O implementations are not portable either, which is
why everyone ends up with having process pools for this or ends up spawning
threads. Go's rationale is that file I/O is probably going to take so long
anyway that it doesn't really cost too much to create another thread (given
that you also run a thread cache of where to hand off the domain). This URI
has a high-level overview of the Go style:

http://morsmachine.dk/go-scheduler

and there are nice isomorphisms to the concept of fiber (G) and domain (P)
and thread (M).


-- 
J.

[-- Attachment #2: Type: text/html, Size: 2382 bytes --]