-
Notifications
You must be signed in to change notification settings - Fork 605
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: 06822ff0764a
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: 415b1c8aa3c1
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 8 commits
- 32 files changed
- 3 contributors
Commits on Jun 2, 2016
-
When calling fork(), we hold all running threads to keep them in known states across the call to fork(). In the child process, the only thread that persists is the thread that called fork(). If another thread was about to write to the logger and got suspended before unlocking the logger mutex, the mutex will be locked in the child and will block any other thread that tries to lock it. The thread in the parent that would have unlocked the lock won't exist in the child. An alternative would be for the thread calling fork to hold all the relevant locks before calling fork(), and then unlocking them all after fork() in the child. Functionally, that wouldn't be any different and would impose additional costs before the fork(). All code needs to be audited for any locks that could be held across a fork() call and all those should be re-init'd in the child.
Configuration menu - View commit details
-
Copy full SHA for 26df90a - Browse repository at this point
Copy the full SHA 26df90aView commit details
Commits on Jun 3, 2016
-
Improved logging of subprocess creation.
The log will now reliably include the non-core method that invoked the spawn, backtick, fork, or exec command. This will point to the application code or rubygems code, rather than the Rubinius core library. The location in the app code is much more useful typically than the location in the Rubinius core library code.
Configuration menu - View commit details
-
Copy full SHA for 47d2e96 - Browse repository at this point
Copy the full SHA 47d2e96View commit details -
Configuration menu - View commit details
-
Copy full SHA for 949b25e - Browse repository at this point
Copy the full SHA 949b25eView commit details
Commits on Jun 4, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 2310fd3 - Browse repository at this point
Copy the full SHA 2310fd3View commit details -
Configuration menu - View commit details
-
Copy full SHA for fca58e9 - Browse repository at this point
Copy the full SHA fca58e9View commit details -
Merge pull request #3659 from rubinius/finalizers
Reworked finalizer mechanism.
Configuration menu - View commit details
-
Copy full SHA for 26403b2 - Browse repository at this point
Copy the full SHA 26403b2View commit details -
Configuration menu - View commit details
-
Copy full SHA for ba08476 - Browse repository at this point
Copy the full SHA ba08476View commit details -
Removed double finalization bandaid.
We need to ensure this is fixed now.
Configuration menu - View commit details
-
Copy full SHA for 415b1c8 - Browse repository at this point
Copy the full SHA 415b1c8View commit details
There are no files selected for viewing