# Multicore compatibility **URL:** \ **Category:** Ecosystem\ **Tags:** multicore\ **Created:** [May 6, 2018, 7:00pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958 "2018-05-06T19:00:26Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [May 6, 2018, 7:00pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/1 "2018-05-06T19:00:26Z")
So I finally reached a good stopping point with my other side projects and spent some time yesterday investigating what it would take to bring them up on the multicore variant of the OCaml toolchain. Answer: it looks tantalizingly possible. It wasn’t hard to fix OMake, for example, not to use _effect_ as a variable name. Other things look more troubling. The tagged 4.06.1 release appears not to include an important C-language header file in its installation, and I think that might be fixed on trunk already. Other things look moderately difficult for a newcomer to approach, but I feel like I might be able to wrestle them to the ground if nobody better at these jobs have time for them. For example, I noticed that the _ocaml-migrate-parsetree_ project needs to be improved with comprehension of the new _effect_ syntax. I spent some time yesterday investigating that, and I haven’t cracked it yet. Nevertheless, it still seems like something I can do provided with enough time on the calendar— my day job is intense and I have to steal time at home after everyone in the house is asleep to work on my side projects. Question: what is everyone else working on to make multicore compatibility with the popular packages in the default OPAM repository happen? I’d like to contribute where I can, and I don’t want to duplicate work that somebody else might be able to get done faster. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [May 7, 2018, 6:35pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/2 "2018-05-07T18:35:26Z")
Update: I have the _ocaml-migrate-parsetree_ project updated and passing its tests. Now to tackle the _ppx\_tools_ project, which looks like it has similar issues related to the introduction of the new **effect** keyword. ---
**Author:** ![avsm](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/avsm/32/6_2.png) [@avsm](https://discuss.ocaml.org/u/avsm)\ **Post date:** [May 8, 2018, 8:42am UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/3 "2018-05-08T08:42:30Z")
Thanks, this is really helpful! Bear in mind that the multicore repository is still a work-in-progress and not an official part of the language. Having said that, it’s extremely useful to be able to differentially compile the stable opam universe against the multicore one, and avoiding the use of the `effect` keyword is one good fix that doesn’t adversely affect anything. Things might get more complex when it comes to adding experimental features to ocaml-migrate-parsetree – it might be better to do a lightweight fork there and maintain a patch in an opam-multicore remote. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [May 8, 2018, 3:01pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/4 "2018-05-08T15:01:00Z")
Yeah, I know it’s work in progress. Did I mention that I am REALLY champing at the bit to have algebraic effects in the language? So I opened an issue on the _opam-multicore_ remote to cover this problem of how to stage the required changes. Due to the design of the _ocaml-migrate-parsetree_ project, it would be inappropriate to pull the necessary changes into its master until the multicore variant has a release vehicle planned in the OCaml project. My preferred approach would be to keep the necessary changes on a development branch and put a package for it into the opam-multicore remote. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [May 13, 2018, 12:52pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/5 "2018-05-13T12:52:17Z")
I’ve now opened pull requests for the _opam-multicore_ remote repository that adds multicore variants for the _ppx\_tools_ and _omake_ projects (and their dependencies). The _omake_ patch was a little interesting because it make fairly extensive use of the C foreign-function interface, and the new C primitive API changes are not so well documented yet. ---
**Author:** ![Freyr666](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/freyr666/32/591_2.png) [@Freyr666](https://discuss.ocaml.org/u/Freyr666)\ **Post date:** [May 13, 2018, 5:44pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/6 "2018-05-13T17:44:16Z")
Considering how far we are from mainlining of the multicore branch I’m not sure if there is any sense in porting something to multicore (beyond benchmarking purposes). I’m pretty sure your experience could be very helpful in [finishing up](https://github.com/ocamllabs/ocaml-multicore/projects/3) the multicore branch itself. ---
**Author:** ![darioteixeira](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/darioteixeira/32/1149_2.png) [@darioteixeira](https://discuss.ocaml.org/u/darioteixeira)\ **Post date:** [May 13, 2018, 5:54pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/7 "2018-05-13T17:54:18Z")
Once it becomes certain that `effect` will indeed become a new keyword in a not too distant future version of the compiler, I reckon it would help the transition if upcoming releases before multicore would issue a warning if `effect` were used as an identifier. Or will there be no more major releases after 4.07 and before multicore? 🙂 ---
**Author:** ![Freyr666](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/freyr666/32/591_2.png) [@Freyr666](https://discuss.ocaml.org/u/Freyr666)\ **Post date:** [May 13, 2018, 6:09pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/8 "2018-05-13T18:09:24Z")
> [@darioteixeira](#): > > Once it becomes certain that `effect` will indeed become a new keyword in a not too distant future version of the compiler Depends on what is considered “distant”. KC’s [later tweet](https://twitter.com/kc_srk/status/994535108127404038) states “I am hopeful that we can get all of items sorted by the end of the year.” some it’s quite far even from an alpha release. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [May 13, 2018, 8:10pm UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/9 "2018-05-13T20:10:20Z")
I don’t know when all of the multicore efforts might land in the main OCaml distribution, but my experience with the remote that’s been baselined on 4.06.1 has been pretty positive so far. One thing I noticed today is that PR#1003 to bring the C interface changes into mainline seems a bit stalled. Apparently, the documentation needs updating (and I might be able to help out with that) and there were also apparently some efforts underway that might make some of the breaking changes unnecessary (which I’d be curious to see an update here about that). Certainly it would be nice to have the OCAML\_API\_VERSION macro available so that we can begin preparing external projects for any breaking changes in the C interface going forward. I’d be thrilled to have just _that_ in the OCaml 4.07 release. ---
**Author:** ![XVilka](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/xvilka/32/5334_2.png) [@XVilka](https://discuss.ocaml.org/u/XVilka)\ **Post date:** [September 20, 2019, 7:51am UTC](https://discuss.ocaml.org/t/multicore-compatibility/1958/10 "2019-09-20T07:51:09Z")
With some more multicore-related changes landed already in the current OCaml master it might make sense to give it an update maybe?