-
Notifications
You must be signed in to change notification settings - Fork 604
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: rubinius/rubinius
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: aa7814191b3c
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: rubinius/rubinius
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 9088c10dd6f6
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 2 commits
- 5 files changed
- 1 contributor
Commits on Jul 17, 2015
-
Synchronize ThreadGroup#add. Closes #3467.
Ruby generally makes no guarantees about thread safety, however, many accidental "guarantees" are assumed by Ruby programmers because of MRI's global interpreter lock. Rubinius makes internal operaions thread safe but generally does not make any thread safety guarantees for common Ruby objects like Array or Hash instances. It's perfectly possible to "corrupt" an Array by concurrently modifying it without synchronization. ThreadGroup presents an interesting case, however, because it is arguably a system structure. The API of ThreadGroup is minimal, consisting of these methods: add, enclose, enclosed?, list. Of these, only add presents a thread safety issue from the perspective of a potentially "corrupted" structure (ie the list of Threads in the group). It's possible for one Thread to enclose the group and another to get 'false' when calling #enclosed? "after" the other Thread called #enclose. That's not a case we are concerned with. The case of calling #add (which will implicitly also remove the Thread from another group if it is a member) should probably be thread safe. For this reason, we add synchronization around adding (and removing) a Thread from a ThreadGroup.
Configuration menu - View commit details
-
Copy full SHA for cddadf0 - Browse repository at this point
Copy the full SHA cddadf0View commit details -
Configuration menu - View commit details
-
Copy full SHA for 9088c10 - Browse repository at this point
Copy the full SHA 9088c10View commit details
There are no files selected for viewing