What do folks think about creating a test suite specifically for identifying and creating failing test cases around the standard lib? The suite would not be required for PRs but would instead serve as a punch list for finding and fixing code that isn’t thread safe. Once a test is fixed, it could be moved into the main test suite.
The issue with something like this is that writing specs to detect thread safety bugs is quite difficult and often leads to super slow tests. We may not even want the respective test to end up in the main test suite.
The goal with this would be to start a formal list of areas we know to not be thread safe and provide a path to resolution – similar to what was done with the Windows work. Are there other ideas for accomplishing this?
2 Likes
First on that list is to decide what should be thread-safe and what should not be thread-safe. Built in datatypes like Array and Slice should probably not be made thread safe as the performance overhead would basically kill any claims that the language can have of being a performant language.
Second on the list would be to figure out what extra thread-safe things that are needed that need to be created in addition to what already exists today.
4 Likes
Great point. Perhaps for those cases simply pointing out that the class is not thread-safe in the documentation would be sufficient. Having a list of things that need to be made thread-safe and documenting classes that will never be thread-safe feels like enough to mark the parallelism work as generally available IMO.
1 Like