[ANN] Lwt.6.0.0~alpha (direct-style)

If that turns up issues, I suppose one work-around, albeit sub-optimal, is to restore the effect of Lwt_unix.(set_default_async_method Async_none), and copiously document the need to call it if invoking anything in Lwt_process or Lwt_unix.fork and Lwt_unix.system and so forth. But the best advice is probably not to try spawning new processes in any Lwt program.

I think @raphael-proust 's answer is excellent, but I’d like to add a couple things:

  • the implementation is roughly 130 loc, some of which related to local storage, so it’s reasonable to read it all to understand how it works
  • lwt_direct is designed to be a very light addition to lwt that does as little as possible and relies on lwt as much as possible, running in the same scheduler, etc. so it doesn’t add parallelism or a new kind of future.
  • run and await are similar to domainslib’s eponymous functions: await (the desirable part) allows direct style code to wait for promises, but it needs to run in a context with an event handler, hence run.
3 Likes

Not generators, but CPS. https://ocsigen.org/js_of_ocaml/latest/manual/effects.

2 Likes

Small update:

  • The branch lwt-6 now includes the multi-domain feature. You can start the Lwt scheduler once in each domain.
  • There is a known bug causing the direct-style tests to stall (waiting for some file descriptors to be closed). I will make an alpha01 release once this is resolved.

Some more details about the mutli-scheduler model can be found on this earlier announcement/request-for-feedback: Multi-domain, multi-scheduler Lwt

1 Like

It is worth reading the implementation of lwt_direct.ml.

It’s an enjoyable 140 lines of OCaml code (only!).

As all things Lwt and effects, understanding the ā€œnormalā€ scenario is general easy but it quickly gets hairy when exceptions/errors enter the room. But reading lwt_direct.ml is still quite educational !

1 Like

version 6.0.0~alpha01 is now ready (2 packages from ocsigen/lwt at 6.0.0~alpha01 by raphael-proust Ā· Pull Request #28222 Ā· ocaml/opam-repository Ā· GitHub)

Anyone able to test the release on their existing code, I’d welcome the feedback: does it work? There shouldn’t be breakages but then there might. If you are not sure how to test or what to test, don’t hesitate to ask (on here or via dm or via discord).

Loving this, but unless I’m mistaken, lwt_direct depends on lwt.unix, making it unusable with jsoo ?

It does.
I think it can be made to work with jsoo but jsoo needs to provide an equivalent of the scheduler hooks. Pretty sure this is doable. One of the alpha bumps (maybe alpha02 maybe alpha03) will focus on jsoo.

Things that need to happen before a non-alpha release

  • make lwt_direct jsoo compatible
  • notify all packages that depend on (the long long deprecated) Lwt_main.exit_hooks (and other such hooks) so they use Lwt.Exit_hooks (and such) instead
  • notify all packages that depend on (the long long deprectaed) lwt_log library to use logs_lwt instead
  • restore backwards compatibility of send_notification and provide a separate send_notification_to_other_domain function
  • a lot of testing
  • whatever else testing uncovers
5 Likes