domainslib
domainslib copied to clipboard
ocaml-multicore
Parallel Programming over Domains
I could not tell whether a newly created pool "owns" the current domain. In one of the test files, there are consecutive calls to `setup_pool`: https://github.com/ocaml-multicore/domainslib/blob/15f04f3e3dfed3e6d1f96e0bfc4525bfc590355b/test/test_task.ml#L40-L41 Therefore, it seems okay...
The OCaml 5.0 includes `Domain.recommended_domain_count` which seems to be a reasonable default value for `Task.setup_pool`. Making the argument optional is code-compatible with existing code. This would also create a mechanism...
It might be useful (at least experimentally) to add an interface that allows the user to easily: - query the number of CPUs in a system - query the NUMA...
I realise the library's API and documentation are still a work in progress, but currently it doesn't seem to fully leverage the type system to ensure proper usage. Case in...
I'm currently experimenting with a [ThreadSanitizer instrumentation pass for OCaml](https://github.com/OlivierNicole/ocaml/wiki/ThreadSanitizer-for-OCaml) that allows to detect some data races in OCaml programs. When running Domainslib's test suite, ThreadSanitizer reported two possible data...
I notice there's no way to exclude the first domain from the Task pool. Is this a design invariant? One concern I have with this is that in some environments...
Is the multi-channel implementation something that Multicore OCaml users would likely require? Domaslib provides FIFO channels. Would the Non-FIFO multi-channel implementation be useful additionally? One downside is that multi-channel does...
It will be useful to have a way to iterate over all the pools that are created in domainslib. One use case is to teardown all the pools. But there...
There seem to be a bug in channel implementation using mutex+condition variable as implemented in PR #17 which causes [task_exn](https://github.com/ocaml-multicore/domainslib/blob/master/test/task_exn.ml) test to deadlock or loop infintely. The bug manifest itself...
Array initialisation is likely to be the source of bottlenecks in parallel workloads. Array initialisation for arbitrary typed elements needs to be sequential since the elements need to be initialised...