Why Ocsigen is staying on Lwt (for now)

[patricoferris]

@dinosaure

I would also like to emphasise that attempts have been made to align with picos (which, to my knowledge, has not been done with regard to eio)

I do not know if it constitutes an attempt to align with picos, but I spent some time and effort porting the core of eio to picos and posted about it in on this topic’s counterpart over a year ago:

[ANN] Ocsigen migrating to effect-based concurrency

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 Fibe…

I think there would not be too many blockers with the right amount of effort (maybe that is naive). Perhaps this is a viable way forward for shared concurrency primitives? It seems to me that each of the direct-style schedulers cater to quite different audiences:

• Eio is capability-based and opts for an explicit structured concurrency.
• Miou (correct me if I am wrong) cares a lot about availability in its design and scheduling.
• Moonpool is geared towards CPU-bound workloads that need parallelisation.

Which is great! And if we go the san-io approach (and the bytesrw approach) then all we have to agree on is how to store our bytes !