-
Notifications
You must be signed in to change notification settings - Fork 123
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
Fixes #1167 #1225
Fixes #1167 #1225
Conversation
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.
Seems like a reasonable solution to me, although I haven't tested that it works.
We should probably remove the other handler, though.
@yav, any objections if I rebase this and get it merged? |
@robdockins nope, go for it, I was waiting for the CI to get sorted out, but I don't think the failures are important. |
This should avoid a potential (rare) race condition where the callback for a dead solver runs after a new solver has already been started, which would result in a "lost" solver process just hanging around
Update simple-smt version and enable `-threaded` runtime. This tracks the changes from GaloisInc/cryptol#1225 The threaded runtime is necessary to keep `waitForProcess` from stalling all threads in simple-smt.
Update simple-smt version and enable `-threaded` runtime. This tracks the changes from GaloisInc/cryptol#1225 The threaded runtime is necessary to keep `waitForProcess` from stalling all threads in simple-smt.
Update simple-smt version and enable `-threaded` runtime. This tracks the changes from GaloisInc/cryptol#1225 The threaded runtime is necessary to keep `waitForProcess` from stalling all threads in simple-smt.
This requires newer version simple-smt, which supports calling back into
the program when the solver exits