| authors |
|
| changes-files | |
| depends | |
| homepage | |
| issues | |
| license |
|
| license-files | |
| maintainers |
|
| online-doc | |
| readme-files | |
| repo |
|
| version |
|
Hmap Heterogeneous value maps.Hmap Heterogeneous value maps.| authors |
|
| changes-files | |
| depends | |
| homepage | |
| issues | |
| license |
|
| license-files | |
| maintainers |
|
| online-doc | |
| readme-files | |
| repo |
|
| tags | |
| version |
|
Browse by name, by tag, the standard library and the OCaml manual (online, latest version).
Generated for /home/runner/work/moonpool/moonpool/_opam/lib
Browse by name, by tag, the standard library and the OCaml manual (online, latest version).
Generated for /root/w/_opam/lib
Lwt is a concurrent programming library for OCaml. It provides a single data type: the promise, which is a value that will become determined in the future. Creating a promise spawns a computation. When that computation is I/O, Lwt runs it in parallel with your OCaml code.
OCaml code, including creating and waiting on promises, is run in a single thread by default, so you don't have to worry about locking or preemption. You can detach code to be run in separate threads on an opt-in basis.
Here is a simplistic Lwt program which requests the Google front page, and fails if the request is not completed in five seconds:
open Lwt.Syntax
+index (lwt.index) Package lwt 5.9.2
Introduction
Lwt is a concurrent programming library for OCaml. It provides a single data type: the promise, which is a value that will become determined in the future. Creating a promise spawns a computation. When that computation is I/O, Lwt runs it in parallel with your OCaml code.
OCaml code, including creating and waiting on promises, is run in a single thread by default, so you don't have to worry about locking or preemption. You can detach code to be run in separate threads on an opt-in basis.
Here is a simplistic Lwt program which requests the Google front page, and fails if the request is not completed in five seconds:
open Lwt.Syntax
let () =
let request =
@@ -22,4 +22,4 @@ let () =
| Some response -> print_string response
| None -> prerr_endline "Request timed out"; exit 1
-(* ocamlfind opt -package lwt.unix -linkpkg example.ml && ./a.out *)
In the program, functions such as Lwt_io.write create promises. The let%lwt ... in construct is used to wait for a promise to become determined; the code after in is scheduled to run in a "callback." Lwt.pick races promises against each other, and behaves as the first one to complete. Lwt_main.run forces the whole promise-computation network to be executed. All the visible OCaml code is run in a single thread, but Lwt internally uses a combination of worker threads and non-blocking file descriptors to resolve in parallel the promises that do I/O.
Tour
Lwt compiles to native code on Linux, macOS, Windows, and other systems. It's also routinely compiled to JavaScript for the front end and Node by js_of_ocaml.
In Lwt,
- The core library
Lwt provides promises... - ...and a few pure-OCaml helpers, such as promise-friendly mutexes, condition variables, and mvars.
- There is a big Unix binding,
Lwt_unix, that binds almost every Unix system call. A higher-level module Lwt_io provides nice I/O channels. Lwt_process is for subprocess handling.Lwt_preemptive spawns system threads.
Installing
- Use your system package manager to install a development libev package. It is often called
libev-dev or libev-devel. opam install conf-libev lwt
Additional Docs
- Manual (Online manual).
- Concurrent Programming with Lwt is a nice source of Lwt examples. They are translations of code from Real World OCaml, but are just as useful if you are not reading the book.
- Mirage Lwt tutorial.
- Example server written with Lwt.
API: Library lwt
This is the system-independent, pure-OCaml core of Lwt. To link with it, use (libraries lwt) in your dune file.
Lwt Asynchronous programming with promises.Lwt_list List helpersLwt_stream Data streamsLwt_result Explicit error handlingLwt_mutex Cooperative locks for mutual exclusionLwt_condition ConditionsLwt_mvar Mailbox variablesLwt_switch Lwt switchesLwt_pool External resource pools.
API: Library lwt.unix
This is the system call and I/O library. Despite its name, it is implemented on both Unix-like systems and Windows, although not all functions are available on Windows. To link with this library, use (libraries lwt.unix) in your dune file.
Lwt_unix Cooperative system callsLwt_main Main loop and event queueLwt_io Buffered byte channelsLwt_process Process managementLwt_bytes Byte arraysLwt_preemptive This module allows to mix preemptive threads with Lwt cooperative threads. It maintains an extensible pool of preemptive threads to which you can detach computations.Lwt_fmt Format API for Lwt-powered IOsLwt_throttle Rate limiters.Lwt_timeout Cancelable timeouts.Lwt_engine Lwt unix main loop engineLwt_gc Interaction with the garbage collectorLwt_sys System informations.
Package info
changes-files license-files readme-files
+(* ocamlfind opt -package lwt.unix -linkpkg example.ml && ./a.out *)In the program, functions such as Lwt_io.write create promises. The let%lwt ... in construct is used to wait for a promise to become determined; the code after in is scheduled to run in a "callback." Lwt.pick races promises against each other, and behaves as the first one to complete. Lwt_main.run forces the whole promise-computation network to be executed. All the visible OCaml code is run in a single thread, but Lwt internally uses a combination of worker threads and non-blocking file descriptors to resolve in parallel the promises that do I/O.
Lwt compiles to native code on Linux, macOS, Windows, and other systems. It's also routinely compiled to JavaScript for the front end and Node by js_of_ocaml.
In Lwt,
Lwt provides promises...Lwt_unix, that binds almost every Unix system call. A higher-level module Lwt_io provides nice I/O channels.Lwt_process is for subprocess handling.Lwt_preemptive spawns system threads.libev-dev or libev-devel.opam install conf-libev lwtlwtThis is the system-independent, pure-OCaml core of Lwt. To link with it, use (libraries lwt) in your dune file.
Lwt Asynchronous programming with promises.Lwt_list List helpersLwt_stream Data streamsLwt_result Explicit error handlingLwt_mutex Cooperative locks for mutual exclusionLwt_condition ConditionsLwt_mvar Mailbox variablesLwt_switch Lwt switchesLwt_pool External resource pools.lwt.unixThis is the system call and I/O library. Despite its name, it is implemented on both Unix-like systems and Windows, although not all functions are available on Windows. To link with this library, use (libraries lwt.unix) in your dune file.
Lwt_unix Cooperative system callsLwt_main Main loop and event queueLwt_io Buffered byte channelsLwt_process Process managementLwt_bytes Byte arraysLwt_preemptive This module allows to mix preemptive threads with Lwt cooperative threads. It maintains an extensible pool of preemptive threads to which you can detach computations.Lwt_fmt Format API for Lwt-powered IOsLwt_throttle Rate limiters.Lwt_timeout Cancelable timeouts.Lwt_engine Lwt unix main loop engineLwt_gc Interaction with the garbage collectorLwt_sys System informations.| authors |
|
| changes-files | |
| depends | |
| homepage | |
| issues | |
| license |
|
| license-files | |
| maintainers |
|
| online-doc | |
| readme-files | |
| repo |
|
| version |
|
Moonpool_lwt Lwt_engine-based event loop for Moonpool.Moonpool_lwt Lwt_engine-based event loop for Moonpool.| authors |
|
| changes-files | |
| depends | |
| homepage | |
| issues | |
| license |
|
| maintainers |
|
| readme-files | |
| repo |
|
| version |
|
Moonpool MoonpoolMoonpool_dpool Static pool of domains.Moonpool_forkjoin Fork-join primitives.Moonpool_private Moonpool MoonpoolMoonpool_dpool Static pool of domains.Moonpool_forkjoin Fork-join primitives.Moonpool_private | authors |
|
| changes-files | |
| depends | |
| homepage | |
| issues | |
| license |
|
| maintainers |
|
| readme-files | |
| repo |
|
| tags | |
| version |
|
This packages contains the core Picos interface library and auxiliary libraries for dealing with the OCaml multithreading architecture.
Picos A systems programming interface between effects based schedulers and concurrent abstractions.Picos_domain Minimalistic domain API available both on OCaml 5 and on OCaml 4.Picos_thread Minimalistic thread API available with or without threads.posix.Picos is a systems programming interface between effects based schedulers and concurrent abstractions. Picos is designed to enable an ecosystem of interoperable elements of effects based cooperative concurrent programming models such as
If you are the author of an application level concurrent programming library or framework, then Picos should not fundamentally be competing with your work. However, Picos and libraries built on top of Picos probably do have overlap with your work and making your work Picos compatible may offer benefits:
Of course, interoperability does have some costs. It takes time to understand Picos and it takes time to implement Picos compatibility. Implementing your programming model elements in terms of the Picos interface may not always give ideal results. To address concerns such as those, a conscious effort has been made to keep Picos as minimal and unopinionated as possible.
Picos is essentially an interface between schedulers and concurrent abstractions. Two phrases, Picos compatible and Implemented in Picos, are used to describe the opposing sides of this contract.
The idea is that schedulers provide their own handlers for the Picos effects. By handling the Picos effects a scheduler allows any libraries built on top of the Picos interface to be used with the scheduler. Such a scheduler is then said to be Picos compatible.
A scheduler is just one element of a concurrent programming model. Separately from making a scheduler Picos compatible, one may choose to implement other elements of the programming model, e.g. a particular approach to structuring concurrency or a particular collection of communication and synchronization primitives, in terms of the Picos interface. Such scheduler agnostic elements can then be used on any Picos compatible scheduler and are said to be Implemented in Picos.
The core of Picos is designed and developed with various goals and principles in mind.
The documentation of the concepts includes design rationale for some of the specific ideas behind their detailed design.
Picos aims to be unopinionated and flexible enough to allow higher level libraries to provide many different kinds of concurrent programming models. While it is impossible to give a complete list of what Picos does not dictate, it is perhaps illuminating to explicitly mention some of those:
Let's build an incredible ecosystem of interoperable concurrent programming libraries and frameworks!
Many operation in the Picos libraries use non-blocking algorithms. Unless explicitly specified otherwise,
| changes-files | |
| license-files | |
| readme-files |
This packages contains the core Picos interface library and auxiliary libraries for dealing with the OCaml multithreading architecture.
Picos A systems programming interface between effects based schedulers and concurrent abstractions.Picos_domain Minimalistic domain API available both on OCaml 5 and on OCaml 4.Picos_thread Minimalistic thread API available with or without threads.posix.Picos is a systems programming interface between effects based schedulers and concurrent abstractions. Picos is designed to enable an ecosystem of interoperable elements of effects based cooperative concurrent programming models such as
If you are the author of an application level concurrent programming library or framework, then Picos should not fundamentally be competing with your work. However, Picos and libraries built on top of Picos probably do have overlap with your work and making your work Picos compatible may offer benefits:
Of course, interoperability does have some costs. It takes time to understand Picos and it takes time to implement Picos compatibility. Implementing your programming model elements in terms of the Picos interface may not always give ideal results. To address concerns such as those, a conscious effort has been made to keep Picos as minimal and unopinionated as possible.
Picos is essentially an interface between schedulers and concurrent abstractions. Two phrases, Picos compatible and Implemented in Picos, are used to describe the opposing sides of this contract.
The idea is that schedulers provide their own handlers for the Picos effects. By handling the Picos effects a scheduler allows any libraries built on top of the Picos interface to be used with the scheduler. Such a scheduler is then said to be Picos compatible.
A scheduler is just one element of a concurrent programming model. Separately from making a scheduler Picos compatible, one may choose to implement other elements of the programming model, e.g. a particular approach to structuring concurrency or a particular collection of communication and synchronization primitives, in terms of the Picos interface. Such scheduler agnostic elements can then be used on any Picos compatible scheduler and are said to be Implemented in Picos.
The core of Picos is designed and developed with various goals and principles in mind.
The documentation of the concepts includes design rationale for some of the specific ideas behind their detailed design.
Picos aims to be unopinionated and flexible enough to allow higher level libraries to provide many different kinds of concurrent programming models. While it is impossible to give a complete list of what Picos does not dictate, it is perhaps illuminating to explicitly mention some of those:
Let's build an incredible ecosystem of interoperable concurrent programming libraries and frameworks!
Many operation in the Picos libraries use non-blocking algorithms. Unless explicitly specified otherwise,
| authors |
|
| changes-files | |
| depends | |
| homepage | |
| issues | |
| license |
|
| license-files | |
| maintainers |
|
| readme-files | |
| repo |
|
| version |
|
Thread_local_storage Thread local storageThread_local_storage Thread local storage