OCaml Weekly News

"None" is a valid response. Maybe you don't want to use parallelism in your Lwt-based codebase.

I can see several reasonable uses:

• a worker pool so you dispatch your server's requests to different cores (but you don't really need to rewrite much of your code, you can keep your lwt handlers, just set up a few domains and a few streams to send work around)
• having mutliple schedulers into which you can run lwt bits of code (e.g., via run_in_domain: Domain.id -> (unit -> 'a Lwt.t) -> 'a, the multi-domain equivalent to run_in_main) from a "proper" multi-domain code

and also some maybe less reasonable uses:

• writing some mixed lwt and regular old-fashion just-Unix blocking code, and passing it off to a separate domain so it doesn't block your main scheduler

Currently, the WIP version, allows you to attach callbacks to promises regardless of which domain they were created in (safe to "read" any promise). It means that promises are not attached to a particular domain, but callbacks are.

OTOH there are no efforts made to prevent data-races for wakeners (unsafe to "write" the same promise from two different domains). In most cases, Lwt.wakeup (and friends) should only be used to create new Lwt-friendly abstractions (e.g., lache) so there is little reason for them to move across domains. Still, is that something that should be taken into account?

More generally, should the domain-safe abstractions replace the existing ones (e.g., should Lwt_stream make it safe to push/read from the same stream in parallel) or should there be new domain-safe abstractions (e.g., an additional Lwt_stream_par)? And what performance cost for single-domain programs is acceptable in order to make multi-domain programs safe?

Would it be better to offer one scheduler per thread? Is there little point in offering unlimited schedulers to begin with?

• :dragon_face: Fixed a handful of bugs in opam install --deps-only <local dir> more visible in 2.4, where some actions would use the local packages' definition or write to the internal opam state as if they were actually pinned (#6529, #6532, #6501, #6535)
• :yarn: Change the behaviour of --deps-only, where it no longer requires unicity of package version between the request and the installed packages. In other words, if you have pkg.1 installed, installing dependencies of pkg.2 no longer removes pkg.1. This also allows to install dependencies of conflicting packages when their dependencies are compliant (#6520)
• :firecracker: Fixed a couple of regressions which would make opam update crash in some cases (#6513, #6527)
• :window: Improve the prebuilt Windows binaries by including Cygwin's setup-x86_64.exe in the binary itself as fallback, in case cygwin.com is inaccessible (#6498, #6538)

:open_book: You can read our blog post for more information, and for even more details you can take a look at the release note or the changelog.

The upgrade instructions are unchanged:

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.4.0~beta1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.4.0~beta1"

Please report any issues to the bug-tracker.

Happy hacking, <> <> The opam team <> <> :camel: