[ANN] Ocsigen migrating to effect-based concurrency

We’re delighted to announce that the Ocsigen project has just launched one of its most ambitious changes: moving from Lwt to effects-based concurrency.

If this experiment goes well, it will be another step towards simplifying Web development in OCaml, by eliminating the need for monads.

Of course we will try to make this transition as smooth as possible, by providing a compatibility interface for application developers, and tools to help Web and mobile developers to do the transition themselves if they want to. These tools will be released in order to help other projects to do the transition and avoid incompatibilities between OCaml libraries as much as possible.

This work was made possible thanks to the support of the NGI Zero Core fund through the Nlnet foundation, and is perfomed by Tarides.

Read the full announcement by Tarides.

14 Likes

If I remember correctly, I read somewhere that the development of eio was paused (and indeed it seems there’s not much activity on the repo these days), are you going to use it as announced or are you considering using something actively maintained (miou for instance) ?

We will try to remain as neutral as possible with regard to the choice of the library, in order to be able to switch to another one or even let the choice to the app developer in the future.

For our first experiments, we are looking towards Eio and Picos. Eio is probably the most advanced concurrency library at the moment, and has been chosen by many other projects. Moreover, it is not true that it is not actively maintained (and more generally, a repository with no activity does not mean that the project is not maintained, it might just be in a satisfactory state). Development is on hold because there is no urgent need, but the team is still keeping a close eye on it, as far as I know.

2 Likes

Indeed, eio is in a relaxing stable period and we’re spending the time using it to get real work done and getting used to direct style IO. Your fibre library shouldn’t be ever-shifting under your feet.

4 Likes

Are there plans to make Eio compatible with/closer to Picos? It’d be nice to have a unified interface, at least a unified notion of future and trigger and fiber-local storage…

1 Like

Relaying a question of @Yaron_Minsky on Bluesky because it seems easier to discuss it on the forum, and I’m also curious

I wonder what the plan is for dealing with data races. As I understand it, eio doesn’t have any typeful discipline for determining where interleavings might happen, unlike both async and LWT.

1 Like

I too am not entirely convinced about direct-style programming for concurrent systems. It’s useful to simplify signatures and avoid some functors with type 'a io := 'a Lwt.t, but signatures become less informative overall.


That being said, Lwt is not great in that respect: type information only vaguely relates to interleavings. Specifically, you can have “interleavings” without the Lwt.t type showing up (see this long explanation), and you can have the Lwt.t type show up without any “interleavings” (See this short explanation). (I’m putting interleaving in quotes because it’s a concept of threads which is not actually a thing in Lwt.)

As far as I know Async is more accurate with that regards. (I don’t know if it’s fully accurate, but more than Lwt.)

Still, Lwt offers some type hints relating to yielding. And those hints are useful.

For what it’s worth, I ported (in a hacky way) eio.core to picos a week or two ago, as proof of concept.

open Eio__core

let () =
  Picos_mux_random.run @@ fun () ->
  let p, r = Promise.create () in
  Fiber.both
  (fun () ->
    Printf.printf "Hello Fiber 1\n%!"
    Promise.await p;
    Printf.printf "Bye Fiber 1\n%!")
  (fun () ->
    Printf.printf "Hello Fiber 2\n%!";
    Promise.resolve r ();
    Printf.printf "Bye Fiber 2\n%!");

(* Hello Fiber 1
   Hello Fiber 2
   Bye Fiber 2
   Bye Fiber 1 *)

Porting the schedulers to Picos would take a good bit more effort, but it is very doable from the experimenting I’ve done.

4 Likes

A post was split to a new topic: Direct style for concurrent systems