I've found myself needing to access the underlying file descriptor for a server that calls Eio.Net.accept{,_fork, but the socket is only exposed as a Flow.two_way.

My use case is the sendfile syscall.

problem

⚠️ mediocre code ahead (ref: https://github.com/cdaringe/protohacks/blob/c4e00f6f55b991d780d46f012a460bb8a528c505/lib/server/server.ml#L33-L44)

      let client_addr, r = recv socket buf in
      traceln "ack";

ack is never emitted when empty packets are sent. yes, ack is objectively the wrong debug word in this scenario 😆

i'm using linux in docker, so perhaps something with the libuv bindings? in the wireshark snippet above, you can see the service retrying, hoping i'll send them a response, but sure enough, the first time they send me an empty packet, i'm unable to proceed passed recv

Currently we're forcing a bind in Eio.Net.datagram_socket by obliging the user to pass a sockaddr, this should be optional, an unbound UDP socket binds on the first sendto and the kernel chooses an ephemeral port.

At the moment, there is no easy way to e.g. read one line from a flow.

You can use the Eio branch of Angstrom (https://github.com/talex5/angstrom/tree/effects) for this, but it would be nice not to have to depend on a separate library for something so basic.

This could be as simple as moving the core Angstrom buffer type (https://github.com/talex5/angstrom/blob/effects/lib/parser.ml) into Eio, so that Angstrom itself just adds a load of combinators on top of this, but you can also do simple things yourself.

One design decision is whether a buffered-reader should be an object sub-type of Flow.read, or a separate module. Using a module might be better, as the case of reading from the buffer is often performance critical (whereas occasionally refilling the buffer from the underlying flow is not).

At the moment, paths in Eio are strings, which are used in the context of some base directory. e.g.

Eio.Dir.with_open_in cwd "foo/input.dat" (fun flow -> ...)

This should work well on most systems, but we need to think about how to support Windows too.

Possibilities include:

• Using Unix path strings everywhere and providing a way to import and export Windows paths.
• Using an abstract type for paths.

The Fpath library encodes lots of knowledge about Windows paths. It probably can't be used directly because its paths behave differently depending on the host platform (preventing e.g. a program running on Linux from creating paths that are to be used on Windows). The path rules should probably be per-filesystem instead.

• Find out what other languages do (e.g. look at Python's pathlib, Rust, etc).

As discussed in #301 we might need to abstract Signals.

I've got a working prototype that works on uring and libuv but we have to define some things before I go forward.

1. Do we want to export more signals, less or the same as Sys ?

Sys is a bit conservative and I think we should export more, for example it misses SIGWINCH and SIGINFO (linux doesn't have this but it's popular in Unix).

2. Do we want to restrict what we export ?

Like type signum = Sigint | Sigwhatever, or we just keep accepting an int and if the user wants to use whatever other signal he has, he can.
I think we should keep taking an int, but do some discovery ourselves (for the value of SIGWINCH for example) and export that as a
val sigwinch : int
Worth noting that the default ocaml signal interface accepts arbitrary integers so that would be no issue, also not an issue with Luv.

3. What do we do with signals that are not supported ?

Do we want to fail hard, fail silently or give it a "button" to control the behavior, this is likely very relevant for windows as they have only a small set of signals.

Hi! This project looks excellent!

I was trying out the example in the README:

#require "eio_main";;
open Eio.Std;;

let main ~stdout = Eio.Flow.copy_string "hello World" stdout
Eio_main.run @@ fun env -> main ~stdout:(Eio.Stdenv.stdout env)
;;

This is failing with Unix.Unix_error(Unix.ENOMEM, "io_uring_register_buffers", "").

There is sufficient free RAM available, so I expect that this is due to some system limit but have no idea how to debug it and can't find any documentation on this error either.

Eio's Ctf module provides a ring-buffer for storing trace events. Currently, this only works for a single domain. OCaml has its own CTF-based eventlog system (https://ocaml.org/manual/instrumented-runtime.html) and we should probably just use that somehow. It might not currently support user-defined events. There's also a proposal to replace it with eventring (ocaml-multicore/ocaml-multicore#793), which says:

This implementation is designed to be open for extension to user tracing events in the future, as well as integration with statmemprof (e.g continuous allocation profiling).

/cc @sadiqj

I'm rewriting https://github.com/lessp/fetch into an ocaml5 cohttp-eio client. But I require design help around eio_main calls.

1. Is it reasonable to have each http request call Eio_main.run itself? Or should each fetch call expect an env object? piaf passes both env and eio switch to each request. It makes sense to pass these two as args to maximize the flexibility.
2. If our implementation requires env and sw, how should I best update this fetch signature: link?

One option is make env and sw optional and generic, such that functor implementations (lwt, async) that don't use eio can ignore it.

  val fetch :
    ?env:'a ->
    ?sw:'b ->
    ?body:string ->
    ?headers:Headers.t list ->
    ?meth:Method.t ->
    string ->
    (Response.t, string) result promise

on a fresh new switch with 5.0.0+trunk, I try to install eio: opam install eio, and get this:

[ERROR] The compilation of eio.0.5 failed at "dune build -p eio -j 19 --promote-install-files=false @install".
[…]
# File "lib_eio/core/debug.ml", line 32, characters 16-25:
# 32 |     | exception Unhandled -> default_traceln
#                      ^^^^^^^^^
# Error: This variant pattern is expected to have type exn
#        There is no constructor Unhandled within type exn

Usually you can "connect" a UDP socket and use normal writes and reads.
In former times a sendto on UDP was a connect+write, at the very least this should allow the kernel to cache a route lookup and etc.

Most signatures that abstract over Lwt / Async currently define an interface to be implemented by the I/O runtime.

Part of that interface is usually:

type +'a t

I took a stab at implementing one of these (Caqti, in particular) for my own use, and I was trying to use an Eio.Promise.t (which is itself defined as type !'a t). The OCaml compiler doesn't seem to like it:

Error: In this definition, expected parameter variances are not satisfied.
       The 1st type parameter was expected to be covariant,
       but it is injective invariant.

Do you have a recommended solution? Is my only hope to implement a wrapper of sorts, or alternatively can the type parameter for Eio.Promise.t be made covariant?

Howdy, I'm running into an issue when installing eio. It appears that there is a conflict with the vendored uring. Calling submodule deinit resolves the issue.

[ERROR] The compilation of eio_main.~dev failed at "dune build -p eio_main -j 3
        --promote-install-files=false @install".

#=== ERROR while compiling eio_main.~dev ======================================#
# context     2.1.0 | linux/x86_64 | ocaml-variants.4.12.0+domains | pinned(git+file:///home/matt/usr/src/mis
c/eio#main#6e739586)
# path        ~/usr/opam/4.12.0+domains/.opam-switch/build/eio_main.~dev
# command     ~/usr/opam/opam-init/hooks/sandbox.sh build dune build -p eio_main -j 3 --promote-install-files
=false @install
# exit-code   1
# env-file    ~/usr/opam/log/eio_main-1151034-395744.env
# output-file ~/usr/opam/log/eio_main-1151034-395744.out
### output ###
# Error: Conflict between the following libraries:
# - "uring" in _build/default/ocaml-uring/lib/uring
# - "uring" in /home/matt/usr/opam/4.12.0+domains/lib/uring
#   -> required by library "eio_linux" in
#      /home/matt/usr/opam/4.12.0+domains/lib/eio_linux

~  opam --version
2.1.0
~  dune --version
2.9.1

Eio needs to support Windows. It was somewhat working with the libuv backend, but the other platforms have stopped using that now (see #434).

• We need OCaml 5.1 for ocaml/ocaml#11846 (OCaml 5.0 segfaults on Windows)

The current plan is:

• Create an eio_windows backend based on eio_posix (#497).
• Get eio_main working with Windows. Get the CI to run one of the examples.
• Set up CI to run the main set of tests on Windows.
• Add initial FS support (#509).
• Finish FS support (see #509 (comment)).
• Go through the backend and implement all the TODOs.
• Improve timer resolution (currently 1 second).

Later, we could convert the backend to use IOCP, but that's not ready yet.

This may be a bit of a weird request, but I've been working on some consensus systems recently, and being able to prioritise internal communications over external ones is quite important

Specifically there for these systems you have multiple nodes communicating with each other (keepalives etc), and also taking client requests. The problem is if there are too many client requests, and no prioritization, the internal communication can end up being delayed waiting for a batch of client requests to be handled. This results in other nodes believing that the leader is dead and hence calling an election.

The way I've fixed this previously was to separate the scheduling spaces (ensuring fairness) via either processes or system threads, one for internal communication and one for external.

One hope I had with effects is that it may be possible to do this prioritisation by using an effect handler to intercept the IO effects, and then assign them to the correct priority level.

This could look something like the following

let client_rpc_handler = ...
let internal_rpc_handler = ...

let intercept f ~priority =
  match f () with
  | x -> x
  | Effect e -> perform_with_priority e ~priority

let main () =
  intercept ~priority:2 client_rpc_handler;
  intercept ~priority:1 internal_rpc_handler;
  ()

And would optimally have the effect of if there are packets waiting on the client sockets and the internal sockets, that it would read from the internal sockets first (generalised over all IO operations).

I understand that this may be impossible to do, but it would be much simpler to do this in the concurrency scheduler. Additionally I'm also not sure whether this is a wrong-headed approach and that another solution would work better.

Many concurrency libraries - both in OCaml¹ and other languages - have some form of fibre-local storage, allowing you to pass implicit context around async code. It would be nice to have similar functionality in eio.

Motivation

I'm currently working on an eio-based project where many tasks are run in parallel. Each task produces a lot of log output, and so it would be useful to track which log messages are associated with each task.

One way to achieve this would be to pass an explicit context around, and use that when logging (such as with logs's ~tag parameter). However, this obviously doesn't allow you to track log messages in external libraries, limiting its usefulness.

One common solution (at least in other languages) is to have some global (thread/fibre-local) variable which stores the current task. This is then be used when processing logs to associate them with the current task.

Other notes

I realise this API may not be desirable for eio, as much of the API is designed around avoiding implicit state. Thought it was worth opening an issue and getting some thoughts before spending too much time thinking about how a potential API would behave.

Would be happy to implement this if it would be useful/helpful.

The network tests can't be run in some cases:

• Docker containers don't have IPv6 loopback by default.
• opam-repo-ci's sandbox on macos prevents using any loopback devices.

This is probably best done by extending MDX. We could perhaps have an exception Mdx_skip_block to indicate that the current block's output should be ignored, or a skip-if=TEST label at the top of the block.

From #274.

Running the tests on macOS fails with:

❯ dune test
File "tests/network.md", line 1, characters 0-0:
diff --git a/_build/default/tests/network.md b/_build/default/tests/.mdx/network.md.corrected
index d2a08c4c69..df05279a8d 100644
--- a/_build/default/tests/network.md
+++ b/_build/default/tests/.mdx/network.md.corrected
@@ -451,8 +451,7 @@ ECONNRESET:
     ignore (Eio.Flow.read a (Cstruct.create 1) : int);
     assert false
   with Eio.Net.Connection_reset _ -> traceln "Connection failed (good)";;
-+Connection failed (good)
-- : unit = ()
+Exception: End_of_file.
 \```

 EPIPE:

I'm using the Luv backend and when trying to load a file bigger than 4gb's the result string always ends up being the first 4gb's of the file.

I'm trying to extend the example of Networking to a client-server echo service, as we learned from network programming course 101.

And here's my code:

open Eio.Std

let run_client ~net ~addr =
  traceln "Connecting to server...";
  Switch.run @@ fun sw ->
  let flow = Eio.Net.connect ~sw net addr in
  Eio.Flow.copy_string "Hello from client" flow;
  let b = Buffer.create 100 in
  Eio.Flow.copy flow (Eio.Flow.buffer_sink b);
  traceln "Client received : %S from server" (Buffer.contents b);
  ;;  

let run_server socket =
  Switch.run @@ fun sw ->
  Eio.Net.accept_sub socket ~sw (fun ~sw flow _addr ->
    traceln "Server accepted connection from client";
    let b = Buffer.create 100 in
    Eio.Flow.copy flow (Eio.Flow.buffer_sink b);
    traceln "Server received: %S" (Buffer.contents b);
    Eio.Flow.copy_string (Buffer.contents b) flow;
    traceln "Server echo: %S to client" (Buffer.contents b);
  ) ~on_error:(traceln "Error handling connection: %a" Fmt.exn);
  traceln "(normally we'd loop and accept more connections here)"
  ;;

  let main ~net ~addr =
    Switch.run @@ fun sw ->
    let server = Eio.Net.listen net ~sw ~reuse_addr:true ~backlog:5 addr in
    traceln "Server ready...";
    Fiber.both
      (fun () -> run_server server)
      (fun () -> run_client ~net ~addr)
  ;;

However, it got stuck as below:

Just wondering if anything I'd missed?

Problem

Per the readme.md, the following should setup a switch for ocaml@5, but errors out as shown

$ opam --version
2.1.1
$ opam switch create 5.0.0~alpha1 --repo=default,alpha=git+https://github.com/kit-ty-kate/opam-alpha-repository.git
[ERROR] No compiler matching `5.0.0~alpha1' found, use `opam switch list-available' to see what is available, or use `--packages'
        to select packages explicitly.

Is kit-ty-kate/opam-alpha-repository still the correct place to get 5 switch? Or, should we be using a std opam variant now that 5 got merged?

Is this function missing from eio, or is one supposed to use the one in the unix library (via eio_unix)?

An observation about README.me, which is great, by the way! (not sure I am supposed to create an issue for this, but where should it go?).

As an eio newbie, this paragraph is not clear to me:
If you call a function **without** giving it access to a switch, then when the function returns **you can** be sure that any fibres it spawned have finished, and any files it opened have been closed. So, a Switch.run puts a bound on the lifetime of things created within it, leading to clearer code and avoiding resource leaks.

I understand it as : "if you call any function wherever in your code, you can be sure that any files it opened have been closed.", which seems weird to me. Should it be "you cannot be sure that..." ? Or should it be "files or resources opened using a specific part of the eio API" ?

May be these two cases could be explained:

• Inside a switch: files & resources attached to the switch are automatically closed when the switch is off.
• Not inside a switch: ... ?

Performing IO operations with the kernel requires giving the kernel the address of a buffer that the GC won't move during the operation. To ensure that, we use Cstruct.t everywhere. However, there are rumours (mirage/ocaml-cohttp#819 (comment)) that regular strings in OCaml 5 are sure to stay put, at least once they're in the major heap.

• Using regular strings/bytes is likely to be slightly faster than a cstruct (which wraps a bigarray).
• It would integrate better with other OCaml APIs.
• We would have to ensure that a buffer is on the major heap (and move it if not) when doing IO. This would involve extra copying if not careful.
• There are severe length restrictions on strings on 32-bit platforms, as the top bits of the length field are used for other things.
• Only cstructs work with memory-mapped data.

Tasks:

• Confirm that OCaml 5 guarantees that strings will not be moved.
• Measure performance difference of strings vs cstructs.

/cc @avsm @kayceesrk

Eio needs to provide a way to create and manage sub-processes (like Lwt_process).

• Must work in programs using multiple domains. Note that Unix.fork cannot be used there.
• API should try to prevent bugs with argument splitting (e.g. avoid error-prone Unix.system style API by default). But also needs to work on Windows, where I think you can't provide an argv.
• Child processes should be attached to a switch by default to avoid leaking them, but need a way to spawn detached sub-processes too.
• Must allow passing pipes, etc, to child processes.
• Must prevent accidentally leaking FDs to child processes. All FDs in Eio are already opened with close-on-exec set for this reason.
• Should provide a simple way to check or report the process's exit status.

Possible sources of inspiration include:

• Lwt_process
• Bos.Cmd
• Feather
• Python's subprocess

Current status:

• #359
• #461
• #464
• #472
• #499

Similarly to how Promise.create has an optional label argument, we could have a similar feature for labelling tasks that are spawned using functions from the Fiber module.

For fork, the signature could be val fork : ?label:string -> sw:Switch.t -> (unit -> unit) -> unit.

For combinators we can choose between:

• val any : ?label:string -> (unit -> 'a) list -> 'a: label all tasks with the same name
• val any_labelled : (string * (unit -> 'a)) list -> 'a : new function to label each task separately

I have a small implementation for this be cause it's very useful to have this when tracing complex Eio programs.

As mentioned on discuss, this name isn't very helpful:

• It's unrelated to Unix.fork, which can be confusing.
• Since adding the switch argument, it doesn't actually copy the calling environment at all.

Should probably be renamed to create, start, spawn, or something like that.

I'm looking forward to the prospect of writing monad-less effects in OCaml. So this library is exciting to me. Thanks for your work on it!

Right now I'm looking to make a single domain application, possibly with Eio. I am aware the Eio is very much a work-in-progress and experimental.

I recently notice ocaml-multicore/ocaml-multicore#770 -- I didn't go deep into the issue but it seems that this is related to domains + effects and since I'm considering only a single domain application it does not impact my use case. Though it's heartening to know that a fix for this was found and promptly applied to the 5.00 multicore branch.

But the questions I have are:

• As you find bugs in multicore while working on Eio, the fixes will be only on the ocaml-multicore 5.00 branch (which is confusingly called 4.14+domains in the opam file). However, Eio is currently built to run on 4.12+domains. How will that work out? Is there a plan to have a Eio for 4.14+domains ?
• The tooling support in 4.14 in general and 4.14+domains in particular is/will be quite poor in the immediate term, so even if you did shift to using Eio on 4.14+domains the development experience would be quite difficult. For instance merlin would not work on 4.14 / 4.14+domains for quite some time. Also the 5.00 (aka 4.14+domains) seems to not compiling too many packages compared to 4.12+domains (according to http://check.ocamllabs.io:8082/ )

I know all these questions relate to this transitional period and things will sort themselves out eventually. But this transition is likely to take many months so I'm wondering if you have any recommendations on what might be the best strategy if I want to use Eio right now.

(Thanks for your time!)

System calls need to be retried if they return EINTR (unless this was due to them being cancelled; you don't always get ECANCELED in that case).

There is some handling already, e.g. here's eio_linux handling EINTR for rw ops:

Check if we need this in more places, and also check the eio_luv backend.

@hannesm notes in mirage/mirage-crypto#155 (comment) that getrandom needs this too.

In Eio 0.3 accept_fork always closes then socket when the function returns. However, the function is supposed to be allowed to close it itself first if it wants to. This results errors such as:

Error handling connection: Cancelled: Invalid_argument("close: file descriptor used after calling close!")

A work-around is to avoid manually closing the socket (there's no very good reason to continue handling a connection after closing it).

Is eio library supposed to be bound to OCaml native applications only? Let's assume that JSOO gets support for effects [1] - will it be possible to have eio compile to JS backend? For context - we have some proprietary project that is based on Lwt and relies on the fact that Lwt can be ran both on native and in JS. For JS we use node.js as target platform. Thinking about possible migration path for OCaml 5.

[1] https://discuss.ocaml.org/t/ocaml-multicore-effects-and-js-of-ocaml/8502

Eio needs to work in browsers and unikernels, so Eio itself must not depend on Unix.

Provide an Eio_unix module to extend the basic API with Unix-specific features, such as extracting a Unix.file_descr from a flow, waiting for an FD to become readable, etc.

At the moment the Eio_linux and Eio_luv backends provide separate APIs for this, but there should be a shared API both can implement.

Right now both Eio.Net.{connect,accept} return a socket, but I didn't find a way to e.g. set TCP_NODELAY on the stream socket. Did I miss an API?

Rahul on discuss pointed out that upstream OCaml spells this as Fiber. We should probably rename it to be consistent with that.

https://grammarist.com/spelling/fiber-fibre/ says:

There is no difference in meaning between fiber and fibre. Fiber is the preferred spelling in American English, and fibre is preferred in all the other main varieties of English.

Given Eio.Dir.t it should be possible to list the contents of the directory

Unix.socketpair takes a Unix.socket_type argument, allowing you to create a datagram socket. However, it still returns a stream socket. Likewise, as_socket always returns a stream socket.

In particular, a zero-length read for a datagram socket does not mean end-of-file (spotted while trying to change the datagram test in network.md to reproduce #340)

• #244 seemed like it had a different scope (specific to accept_fork), so I opened a new one.

• I'm hitting a case where I sometimes end up calling Eio.Flow.close a second time, and that blows up my application

• in cases where it's hard to guarantee that I only call close once, would it be reasonable to implement either one or both of the following?

  1. make Eio.Flow.close not throw (but perhaps leave the other operations throwing?)
  2. (at least) make the exception raised by Eio_luv.Handle.get easier to pattern match against. Right now the pattern needs to be Invalid_argument "close: handle used after calling close!" which feels a bit brittle.

Not sure if I'm doing something wrong, but I've run into the following issue (on the Luv backend).

A fiber waiting on a Eio.Flow.read before another fiber closes it will hang forever, at least for a client type Eio.Net.connect flow.

I've managed to trim it down to the following case:

open Eio.Std

let main env =
  let run_client ~net ~addr =
    traceln "client on";
    Switch.run (fun sw ->
        let flow = Eio.Net.connect ~sw net addr in
        traceln "client <-> server";
        let read_loop () =
          let b = Cstruct.create 4 in
          traceln "client will be stuck after this";
          while true do
            Eio.Flow.read flow b |> ignore;
            traceln "unreachable"
          done
        in
        let d = "Hello from client" in
        traceln "client -> %S" d;
        Eio.Flow.copy_string d flow;
        Fiber.fork ~sw read_loop;
        Eio.Flow.close flow);
    traceln "client off"
  in
  let run_server socket =
    traceln "server on";
    Switch.run (fun sw ->
        Eio.Net.accept_sub socket ~sw
          (fun ~sw:_ flow _addr ->
            traceln "server <-> client";
            let b = Buffer.create 100 in
            Eio.Flow.copy flow (Eio.Flow.buffer_sink b);
            traceln "server <[EOF]- %S" (Buffer.contents b))
          ~on_error:(traceln "Error handling connection: %a" Fmt.exn));
    traceln "server off"
  in

  let net = Eio.Stdenv.net env in
  let addr = `Tcp (Eio.Net.Ipaddr.V4.loopback, 9999) in
  Switch.run @@ fun sw ->
  let server = Eio.Net.listen net ~sw ~reuse_addr:true ~backlog:5 addr in
  Fiber.both (fun () -> run_server server) (fun () -> run_client ~net ~addr)

Where the expected output would be:

+server on
+client on
+client <-> server
+client -> "Hello from client"
+server <-> client
+client will be stuck after this
+server <[EOF]- "Hello from client"
+server off
*hangs forever*

Hi! First off, thanks for the amazing work in eio!

I'd like to have an API for uv_getaddrinfo and uv_getnameinfo. Luv has bindings to these on their DNS module: https://github.com/aantron/luv/blob/0ed668e87ca55d65f4f84422b0dd3381701c71b0/src/DNS.ml

If this feature is welcome in eio, I'd gladly send a PR.

What the title says. Tried with Eio.Time.with_timeout_exn clock 3.0 (fun () -> Eio.Net.connect ~sw net stream). io-uring worked as expected.

@haesbaert wrote:

it seems to hang on lib_eio_linux/tests/test.ml on the very first test

We should try to find out what's causing this. I wrote:

What happens if you just run ./_build/default/lib_eio_linux/tests/test.exe in a loop? It doesn't hang for me.

Can we draw inspiration from Rust's Mutex to make Eio.Mutex a bit more ergonomic? E.g. usage adapted from https://github.com/ocaml-multicore/eio#the-rest-mutex-semaphore-and-condition:

open Eio

let of_path = Mutex.create

let save m data =
  Mutex.use_rw m ~protect:true @@ fun path ->
  Path.save path data ~create:(`Or_truncate 0o644)

let load m = Mutex.use_ro m Path.load

We would need signatures like this:

module Mutex : sig
  type _ t

  val create : 'a -> 'a t
  (** Create in an unlocked state holding the data. *)

  val use_rw : protect:bool -> 'a t -> ('a -> 'b) -> 'b
  (** Lock for read-write access. *)

  val use_ro : 'a t -> ('a -> 'b) -> 'b
  (** Lock for read access. *)
end

Having said that, I realize we don't have borrow/move checking in OCaml so we wouldn't get the same level of safety. But it should make it a bit more ergonomic as the key idea is that a mutex is always paired with its data.

I'm currently fiddling with building a DBus library on top of libsystemd and eio. Really enjoying using eio, though I did have some questions about how best to design the API to fit within eio's model.

The main problem at hand is that one needs to run a background task which waits for the underlying socket to become readable/writable and then gets libsystemd to process its message queue[^1]. I originally had something like this:

let rec process bus = 
  await_event bus;
  sd_bus_process bus;
  process bus

let rec create ~sw () = 
  let bus = (* ... *) in
  Fibre.fork ~sw (fun () -> process bus);
  Switch.on_release sw (fun () -> sd_bus_close bus);
  bus

This obviously doesn't quite do what you want though, as the process fibre keeps the switch open forever.

I've had a quick look at how other structured concurrency libraries handle the problem of background tasks which shouldn't keep the switch open, but haven't had much luck (I realise in most cases it is pretty undesirable). Is there anything obvious in eio I'm missing, or is my best option just to provide an explicit close method which shuts down this task?

I was looking at the object capabilities & API in Eio.

I've been experimenting with something similar in a couple of projects. So here are a couple of things worth discussing since it is early on (even just if just to show us all & document that those are actually bad ideas ;) ):

• the goal is to help the reader so I'd use full words and expressions instead of acronyms: network, file_system, etc.
• instead of multiplying the ~network ~file_system ~clock arguments, I just pack them all in the first argument of every function as an open object that describes what the function needs:
  
  val foo: < network: Network.t; console: Console.t ; .. > -> bar:int -> …
  • type inference does a lot more of the job for us, and the capabilities get in the way only when we actually want to look at them
  • it is very composable so user code can extend it to any other kind of context or state that one may want to pass around.
  • merlin makes writing mlis easier with insert-merlin-type :)
  • when a function does not need something any more it is easier to remove a method from an object type in signatures than unthreading an argument through a whole call stack (but it's also a bit easier to leave unused fields in signatures)
  • it does have the drawback of making every signature a bit heavier
  • In gemini-eio/src/main.ml:74, there is a regular record that is packing things like that (incl the Switch.t!) but it is done in a non-reusable way (because the record is not structural).
• the methods of those objects should not be functions with complicated types because error messages quickly become insane → better have a < network: Network.t ; .. > and put the functions in the Network module (those also would take the object as first argument for composability, and it makes much better documentation anyway)

Could eio support monotonic clock in Stdenv.t like we do the system clock?

It seems that luv raises an exception instead of returning an empty list.

open Eio

let lookup net hostname =
   match Net.getaddrinfo_stream net hostname with
   | [] -> ()
   | _ -> assert false

let () =
  let hostname = "blahblahblah.tarides.com" in
  (assert (Unix.getaddrinfo hostname "" [] = []));
  Eio_main.run (fun env -> lookup env#net hostname)

This returns:

Fatal error: exception Eio_luv.Luv_error(EAI_NONAME) (* unknown node or service *)

I can't currently run this properly on Linux with Uring but I'm assuming it returns [] because Unix.getaddrinfo does.

I think the Stream module in Eio is not a stream in a traditional functional sense.

In particular, it looks more similar to abstractions provided by some other libraries/runtimes under different names:

• Async.Pipe
• Lwt_pipe
• Crystal/Channel
• Go/chan

"Streams" in functional languages tend to be related to one-directional element-wise "stream processing".

My suggestion would be to rename the Eio.Stream module to Eio.Pipe as this seems to be a more used name in the OCaml ecosystem.

What the title says. I tried with io-uring by setting the EIO_BACKEND variable and it seems to work fine.

I tried running the "Hello, world" example from the readme on WSL and got the following exception:

Eio_main.run @@ fun env -> main ~stdout:(Eio.Stdenv.stdout env);;
Exception: Unix.Unix_error(Unix.ENOSYS, "io_uring_queue_init", "")

Here's some more info about my system:

• WSL version: 2
• Windows version: Windows 11 / Version 10.0.22000 Build 22000

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

$ opam list --roots
# Packages matching: root
# Name         # Installed    # Synopsis
eio_main       0.1            Effect-based direct-style IO mainloop for OCaml
ocaml-variants 4.12.0+domains OCaml 4.12.0, with support for multicore domains
utop           2.9.0          Universal toplevel for OCaml

I couldn't get eio to handle my signals while another fiber is running (even if sleeping). Take this pathological case:

open Eio.Std

let () =
  Sys.(
    set_signal
      sigint
      (Signal_handle
         (fun i ->
           Format.eprintf "handle signal: %d@." i;
           exit 0)));
  Eio_main.run (fun _env ->
      Switch.run (fun sw ->
          Fiber.fork ~sw (fun () -> Eio.Time.sleep (Eio.Stdenv.clock _env) 5.)))

You can send ctrl+C to the program while it's running and it won't process it until after 5 seconds (when the eio fiber ends).

Tested on macOS (with eio_luv)