# Multiple domains design question in Eio/etc

**URL:** <https://discuss.ocaml.org/t/multiple-domains-design-question-in-eio-etc/15861>\
**Category:** Learning\
**Tags:** multicore, domainslib, eio\
**Created:** [December 28, 2024, 6:51am UTC](https://discuss.ocaml.org/t/multiple-domains-design-question-in-eio-etc/15861 "2024-12-28T06:51:13Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\
**Post date:** [January 4, 2025, 12:57am UTC](https://discuss.ocaml.org/t/multiple-domains-design-question-in-eio-etc/15861/5 "2025-01-04T00:57:47Z")

</div>

OK, I’ve suggested a multi-core runtime strategy, basically:

```ocaml
let () = Par.run @@ env ->
  ...run on multiple cores...

  (* Distribute slices of the array across all worker domains *)
  let result = Par.sum env large_float_array in
  ...

```

So this takes care of starting up the recommended number of domains and running the app across all of them, while also setting up a way to submit parallelized (ie CPU-intensive) tasks and getting a promise of the result.

This is a POC right now (linked above) but I believe this is a good direction: users don’t need to worry about setting up domains, they don’t need to hand over all of the domains to a specific subsystem like the HTTP server, they don’t need to figure out how many domains to allocate for what.

Of course, this is not thoroughly tested or benchmarked right now; more to come. But happy to discuss more.

---

_[View the full topic](https://discuss.ocaml.org/t/multiple-domains-design-question-in-eio-etc/15861)._