Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hotfix bound threads for workers unsafe calls for llvm #4081

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jberthold
Copy link
Member

Fixes a problem with recently-introduced thread-local storage in the LLVM backend.
We have to make sure that all foreign calls relating to an LLVM-based term evaluation use the same OS thread, which can only be achieved via bound threads .

This PR

  • adds a flag to the generic RPC server in kore-rpc-types to run request worker threads in bound threads (using forkOS)
  • kore-rpc-booster uses this flag for bound threads when an LLVM backend library is used
  • declares the LLVM backend calls unsafe to make executing OS threads block instead of having new OS threads created for concurrent Haskell execution (they won't read HS heap data and never call back into Haskell).

This should protect us against problems related to using thread-local storage in the LLVM backend. Needs to be thoroughly tested before merging, because issues only materialised in proofs with substantial workload and parallel exploration.

PR #4080 uses runInBoundThread on the individual request processing calls instead of running the whole worker thread in the server as a bound thread. This was not solving the problem.

When using foreign libraries that use thread-local state, a program must ensure that foreign calls are always made from the same OS thread, by way of making these calls in _bound threads_, see https://downloads.haskell.org/ghc/latest/docs/libraries/base-4.20.0.0-1f57/Control-Concurrent.html#g:8

This PR
* adds a flag to the generic RPC server in `kore-rpc-types` to request running workers in bound threads. The server will use `forkOS` instead of `forkIO` in this case.
* requests running with bound threads when an LLVM backend library is used.

This _should_ protect us against problems related to using thread-local storage in the LLVM backend. Needs to be thoroughly tested before merging, because issues only materialised in proofs with substantial workload and parallel exploration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant