Eio 1.0 progress tracking

[talex5]

Status of major features needed for Eio 1.0 (a tick means would be OK to ship in its current state):

Backends:

• Linux io_uring.
• Windows support #125 (can release as beta quality)
• Finish eio_posix backend #456

Non-essential backends (but would be good to check that the cross-platform API works for them before 1.0 if possible):

• MirageOS. Prototype (running dream-eio in a unikernel): https://github.com/TheLortex/eio-solo5
• Initial Javascript browser backend #405

Features:

• Concurrency primitives: Fibers, cancellation, promises, streams and semaphores.
• Make Waiters lock-free #382
  Lock-free waiters. Should be faster, and also needed to handle signals correctly.
• Multicore support: spawn new Eio and non-Eio domains.
• Decide and document thread-safety in cross-platform API #387
  Sharing OS resources with other domains.
• Networking: Clients and servers using TCP, UDP and Unix domain sockets.
• Add missing file operations #510
  File-systems: Mostly working, but API is incomplete.
• Signals abstraction #321
  Signal handlers.
• API for spawning sub-processes #126
  Spawning processes.
• Add task/worker pool similar to Domainslib task pool #512
  High-level domain pools API.
• Replace objects with variants #553
• Full tracing support #649

Integrations:

• Lwt_eio.
• Async_eio: proof-of-concept works, but requires changes to async.
• Domainslib (Document how to use Domainslib from Eio #489).

Testing:

• Unit tests (in tests directory).
• Benchmarks for synchronisation primitives (in bench directory).
• Stress tests for synchronisation primitives (in stress directory; currently semaphore only).
• Add more stress tests and benchmarks #450
  Stress tests for OS access.
• Fuzz tests for parsers/serialisers (in fuzz directory).
• Deploy at least one service using it in production.

[avsm]

I'd really like to see if we can get @patricoferris' GCD backend integrated for a 1.0 as well.

[anmonteiro]

What’s Lwt_async?

[patricoferris]

I'd really like to see if we can get @patricoferris' GCD backend integrated for a 1.0 as well.

I have a much better understanding of Eio and concurrency/async IO now, so I'll see if I can bring this backend into shape and see how it's performance is.

What’s Lwt_async?

Possibly a typo :)) and was supposed to be async_eio https://github.com/talex5/async_eio ?

[talex5]

Possibly a typo :)) and was supposed to be async_eio https://github.com/talex5/async_eio ?

Yes! Fixed :-)

[kayceesrk]

js_of_ocaml is is merged now. What would js_of_ocaml support look like?

[patricoferris]

I think there are two backends that would be needed for good jsoo support, one for node and one for the browser. For a quick win in the browser, I think just taking the mock backend's scheduler might be a good place to start and adding whatever things from the standard environment make sense e.g. jsoo has a notion of a fake filesystem which could be the backend for the fs parts of jsoo but jsoo would probably never have a network capability (or not now https://github.com/WICG/direct-sockets)

For node, we just need to wrap the node bindings which are basically libuv. I made a start over here: https://github.com/patricoferris/eio/tree/node/lib_eio_js

[talex5]

For a quick win in the browser, I think just taking the mock backend's scheduler might be a good place to start and adding whatever things from the standard environment make sense

Yep (actually, this is a good place to start for any backend). Eio_main.run is intended for Unix-type systems and it's completely OK for JS applications to use a separate Eio_js.run with a different set of resources.

For node, we just need to wrap the node bindings which are basically libuv. I made a start over here: https://github.com/patricoferris/eio/tree/node/lib_eio_js

Excellent!

BTW, you might want to rebase your node backend on Eio 0.7, as there have been quite a few changes to the error handling since the commit it's based on.

[Lupus]

Is it practical to hand-roll node bindings using jsoo ffi directly nowadays? ts2ocaml can generate bindings out of TypeScript definitions. Bindings will use gen_js_api to actually compile to something that will work on jsoo. For simple libraries ts2ocaml can produce compileable bindings that you can use straight away. For more complex ones like Node API it can save you 80% of work.

How fast can jsoo be with effects? So far the consensus is that it's slow and as an optimization they suggest to avoids CPS transformaton for code that does not use effects. Will Eio code (that is 100% on effects) run fast enough on jsoo to be practical to be used anywhere in production?

[patricoferris]

Is it practical to hand-roll node bindings using jsoo ffi directly nowadays?

It's a fair point, but yes I think it is still practical as there's not that many. I am also firmly in the camp of hand-rolling a bit even if you eventually automate (like hand-writing C stubs before reaching for ctypes) so you are in full control over the bindings to avoid hard to debug problems (e.g. for effects to work the calling convention must use the underlying caml_js_wrap_callback_strict otherwise it won't be registered and I knew Brr made this update fairly quickly, I don't know if gen_js_api and ts2ocaml have ensured this (maybe they already did?)).

How fast can jsoo be with effects?

See the latest PR ocsigen/js_of_ocaml#1384.

As an update for this thread, there's a PR open for the browser backend. #405