Abigael

Audit stdlib for mutable state

30

This is moved from https://github.com/ocaml-multicore/ocaml-multicore/issues/757 This issue tracks the status of auditing stdlib for mutable state. OCaml 5.00 stdlib will have the following guarantees: 1. Memory safety -- no crashes...

Add std gnu11 common cflags

1

While looking at https://github.com/ocaml-multicore/ocaml-multicore/issues/574 with @Kate and @Sudha247 we noticed that it seems there's a discrepancy in what kind of flags OCaml packages are using to build C stubs against...

Possible segfault when a new domain is signalled before it can initialize the domain_state

2

There is a potential issue where a domain (create through `Domain.spawn`) can receive a signal before it can reach its main entrypoint and initialize its thread local data. (namely, `Caml_state`)...

beat.ml failure on Github Action macos runners.

1

I investigate the `beat.ml` failure in the testsuite, on our CI runs. I managed to reproduce the failure on trunk as well, using `macos-latest` and `macos-11`. https://github.com/Engil/ocaml/runs/3995857082?check_suite_focus=true#step:5:25 I am unsure...

This can be triggered when a domain that blocked a specific set of signals ends up in a situation where no other domain can process the signal (for example: it...

Core testsuite workflow

2

This PR aims to implement a workflow to run Core's testsuite once a day. The long run ideal would be to include in a matrix other pieces of Core's ecosystem...

Destroy channel mutexes after fork

1

We do not reset the channel mutexes after fork right now. For example, systhreads does it here in trunk: https://github.com/ocaml/ocaml/blob/trunk/otherlibs/systhreads/st_stubs.c#L419-L427

Parmap seems to segfaults when running its testsuite against Multicore: Excerpt from: http://check.ocamllabs.io:8082/log/1624991904-364a3dc92d821c5de168ef561a9f2a79860cfafc/4.12+domains/bad/parmap.1.2.3 ``` # Parmap warning: result order is not preserved (it was not expected to be). # Speedup...

This run is green: http://check.ocamllabs.io:8082/log/1619567326-891a99961fc79364d145b039f2d497fb76f9e8dd/4.12+domains/good/zmq-lwt.5.1.3 Yet it seems there is indeed a failure in the testsuite, it's just not being caught by zmq: ``` + /home/opam/.opam/4.12.0+domains/bin/dune "build" "-p" "zmq-lwt" "-j"...

Following observations made in #439, there may be an unaccounted case in Multicore-systhreads when the thread chaining for a given domain is not empty on domain termination. It doesn't seem...