4 ms·

I think one major turn off, especially for systems programming, was the lack of multicore threading support (i.e. it had no way to get parallelism using threads

I think one major turn off, especially for systems programming, was the lack of multicore threading support (i.e. it had no way to get parallelism using threads). Does anyone know if this has changed?

atombender 8y ago
Posted a week ago: http://kcsrk.info/slides/mcocaml_gallium.pdf http://kcsrk.info/slides/mcocaml_gallium.pdf Discussion: https://news.ycombinator.com/item?id=17416797 https://news.ycombinator.com/item?id=17416797 In short, expect it merged in mid-to-late 2019, maybe.
ZirconiumX 8y ago
While this is an issue, there are cooperative threading libraries (mainly Lwt and Async, though the community prefers Lwt) which can mitigate most of the reasons you'd need multithreading. Hell, because it's only single threaded, you can mostly ignore locking.
StreamBright 8y ago
Isn't this project aiming to solve that? http://ocamllabs.io/doc/multicore.html http://ocamllabs.io/doc/multicore.html
fpoling 8y ago
One of the fastest web servers is nginx that uses child processes (typically one child per core) and asynchronous IO within the child without any threads. The same model with a parent process that monitor threadless child workers is often used in embedded system. One can and people do exactly the same in OCaml. Surely it requires more code to setup things especially if the child processes need to communicate over shared memory to max the performance, but the big plus is that the resulting system is much more robust. In case of troubles one can just let a child die or even use kill -9 and start a new child. This is not possible with most threading implementations. For example, try to recover from out-of-memory in multi threaded C++/Java/Go etc. application. It is very hard. With threadless children it is almost trivial.
- pjmlp 8y ago
  Plus we have learned the hard way that concurrency and processes are much saner from safety point of view than threads.

atombender 8y ago

Posted a week ago: http://kcsrk.info/slides/mcocaml_gallium.pdf http://kcsrk.info/slides/mcocaml_gallium.pdf Discussion: https://news.ycombinator.com/item?id=17416797 https://news.ycombinator.com/item?id=17416797 In short, expect it merged in mid-to-late 2019, maybe.

ZirconiumX 8y ago

While this is an issue, there are cooperative threading libraries (mainly Lwt and Async, though the community prefers Lwt) which can mitigate most of the reasons you'd need multithreading. Hell, because it's only single threaded, you can mostly ignore locking.

StreamBright 8y ago

Isn't this project aiming to solve that? http://ocamllabs.io/doc/multicore.html http://ocamllabs.io/doc/multicore.html

fpoling 8y ago

One of the fastest web servers is nginx that uses child processes (typically one child per core) and asynchronous IO within the child without any threads. The same model with a parent process that monitor threadless child workers is often used in embedded system. One can and people do exactly the same in OCaml. Surely it requires more code to setup things especially if the child processes need to communicate over shared memory to max the performance, but the big plus is that the resulting system is much more robust. In case of troubles one can just let a child die or even use kill -9 and start a new child. This is not possible with most threading implementations. For example, try to recover from out-of-memory in multi threaded C++/Java/Go etc. application. It is very hard. With threadless children it is almost trivial.

pjmlp 8y ago
Plus we have learned the hard way that concurrency and processes are much saner from safety point of view than threads.