https://github.com/ivg/lwt-parallel

Lwt-enabled distributed computing library
https://github.com/ivg/lwt-parallel

lwt ocaml parallel

Last synced: 3 months ago
JSON representation

Lwt-enabled distributed computing library

• Host: GitHub
• URL: https://github.com/ivg/lwt-parallel
• Owner: ivg
• License: mit
• Created: 2013-08-19T17:48:45.000Z (over 11 years ago)
• Default Branch: master
• Last Pushed: 2022-12-09T16:12:11.000Z (about 2 years ago)
• Last Synced: 2024-10-03T12:28:49.191Z (3 months ago)
• Topics: lwt, ocaml, parallel
• Language: OCaml
• Homepage:
• Size: 88.9 KB
• Stars: 41
• Watchers: 4
• Forks: 4
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
Lwt-enabled Parallel Processing Library

=======================================

This library allows running lwt computations in different OS processes. E.g.,

```ocaml

(* do it once in the beginning  *)

let () = Parallel.init ()

(* ... *)

let puts = Parallel.run Lwt_io.printl in

(* will be printed in a different process *)

puts "hello" >>= fun () ->

```

Implementation Details

----------------------

In general, Unix fork(2) and Lwt do not mix well. There are a few issues. First, Lwt uses regular threads (like pthreads) to handle some system calls, and threads do not play with forks. Next, Lwt promises essentially form a DAG of reference cells that will be cloned into the child process on a fork so that the promises made in parent will be triggered in the child, which is not what you usually want. Last but not least, every fork will clone the whole heap of the current process, which will be result in a time consuming data copying the next time the marks and sweep cycle of the GC is run (which will trigger copy-on-write as it will mark every block).

The solution is to create a snapshot of the process before it starts any lwt-related computations and use this snapshot to fork the new processes. I.e., every time we need to fork a process, instead of running fork(2) in the current process we send a request to the snapshot process which forks a new child and returns the AF_UNIX socket address for communicating with this child. The function to be executed along with the protocol specifications are marshaled via pipe to the snapshot process, where they are copied to the new process space during the fork.