interp: fix data races #839
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change fixes two distinct data races: 1) some global vars of type *itype of the interp package are actually mutated during the lifecycle of an Interpreter. Even worse: if more than one Interpreter instance are created and used at a given time, they are actually racing each other for these global vars. Therefore, this change replaces these global vars with generator functions that create the needed type on the fly. 2) the symbols given as argument of Interpreter.Use were directly copied as reference (since they're maps) when mapped inside an Interpreter instance. Since the usual case is to give the symbols from the stdlib package, it means when the interpreter mutates its own symbols in fixStdio, it would actually mutate the corresponding global vars of the stdlib package. Again, this is at least racy as soon as several instances of an Intepreter are concurrently running. This change fixes the race by making sure Interpreter.Use actually copies the symbol values instead of copying the references.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change fixes two distinct data races:
some global vars of type *itype of the interp package are actually
mutated during the lifecycle of an Interpreter. Even worse: if more than
one Interpreter instance are created and used at a given time, they are
actually racing each other for these global vars.
Therefore, this change replaces these global vars with generator
functions that create the needed type on the fly.
the symbols given as argument of Interpreter.Use were directly copied
as reference (since they're maps) when mapped inside an Interpreter
instance. Since the usual case is to give the symbols from the stdlib
package, it means when the interpreter mutates its own symbols in
fixStdio, it would actually mutate the corresponding global vars of the
stdlib package. Again, this is at least racy as soon as several
instances of an Intepreter are concurrently running.
This change fixes the race by making sure Interpreter.Use actually
copies the symbol values instead of copying the references.