-
Notifications
You must be signed in to change notification settings - Fork 43
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
Hotfix bound threads for workers unsafe calls for llvm #4081
Conversation
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.
This branch seems to fix the issues reported by @PetarMax for the Lido proof with parallel exploration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving with a question.
|
Tests with
(this is from running |
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
kore-rpc-types
to run request worker threads in bound threads (usingforkOS
)kore-rpc-booster
uses this flag for bound threads when an LLVM backend library is usedunsafe
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.