ocaml-multicore / eio Goto Github PK
View Code? Open in Web Editor NEWEffects-based direct-style IO for multicore OCaml
License: Other
Effects-based direct-style IO for multicore OCaml
License: Other
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.
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.
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:
$ 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
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:
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
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.
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?
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.
Tasks:
/cc @avsm @kayceesrk
Eio needs to support Windows. It was somewhat working with the libuv backend, but the other platforms have stopped using that now (see #434).
The current plan is:
eio_windows
backend based on eio_posix (#497).eio_main
working with Windows. Get the CI to run one of the examples.Later, we could convert the backend to use IOCP, but that's not ready yet.
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:
eio/lib_eio_linux/eio_linux.ml
Lines 519 to 527 in 85841dc
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.
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:
The network tests can't be run in some cases:
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.
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
What the title says. I tried with io-uring
by setting the EIO_BACKEND
variable and it seems to work fine.
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*
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).
Could eio support monotonic clock in Stdenv.t
like we do the system clock?
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.
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:
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!)
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).
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)
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
)
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:
"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.
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?
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 ;) ):
network
, file_system
, etc.~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 -> …
insert-merlin-type
:)Switch.t
!) but it is done in a non-reusable way (because the record is not structural).< 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)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'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.
Many concurrency libraries - both in OCaml1 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.
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.
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.
lwt's Lwt.new_key
and async's Async.Execution_context
. While lwt's API is deprecated, its (sometimes) confusing behaviour could hopefully be avoided in eio due to the separation of promises and fibres. ↩
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.
As mentioned on discuss, this name isn't very helpful:
Unix.fork
, which can be confusing.Should probably be renamed to create
, start
, spawn
, or something like that.
I'm rewriting https://github.com/lessp/fetch into an ocaml5 cohttp-eio client. But I require design help around eio_main calls.
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.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
Is this function missing from eio
, or is one supposed to use the one in the unix
library (via eio_unix
)?
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 nameval any_labelled : (string * (unit -> 'a)) list -> 'a
: new function to label each task separatelyI have a small implementation for this be cause it's very useful to have this when tracing complex Eio programs.
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?
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.
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.
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
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.
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.
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).
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.
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.
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.
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
Eio needs to provide a way to create and manage sub-processes (like Lwt_process
).
Unix.fork
cannot be used there.Unix.system
style API by default). But also needs to work on Windows, where I think you can't provide an argv.Possible sources of inspiration include:
Current status:
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'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?
Given Eio.Dir.t
it should be possible to list the contents of the directory
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:
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.
#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?
Eio.Flow.close
not throw (but perhaps leave the other operations throwing?)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.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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.