Skip to content
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

green/native: Be more resilient to spawn failures #15944

Merged
merged 3 commits into from
Jul 30, 2014

Conversation

alexcrichton
Copy link
Member

Previously both spawning mechanisms were not resilient to task failures which were initiated from the task spawning infrastructure.

Closes #15895


use mutex::{StaticNativeMutex, NATIVE_MUTEX_INIT};

static mut TASK_COUNT: atomics::AtomicUint = atomics::INIT_ATOMIC_UINT;
static mut TASK_LOCK: StaticNativeMutex = NATIVE_MUTEX_INIT;

pub fn increment() {
pub struct Token(());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This () is to ensure it can't be constructed outside this module? (Would Token { _force_private: () } be more descriptive?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is indeed correct! Pushed with an explicit field now.

@huonw
Copy link
Member

huonw commented Jul 24, 2014

(Needs a rebase.)

When a new task fails to spawn, it triggers a task failure of the spawning task.
This ends up causing runtime aborts today because of the destructor bomb in the
Task structure. The bomb doesn't actually need to go off until *after* the task
has run at least once.

This now prevents a runtime abort when a native thread fails to spawn.
Previously, the call to bookkeeping::increment() was never paired with a
decrement when the spawn failed (due to unwinding). This fixes the problem by
returning a "bomb" from increment() which will decrement on drop, and then
moving the bomb into the child task's procedure which will be dropped naturally.
Like with libnative, when a green task failed to spawn it would leave the world
in a corrupt state where the local scheduler had been dropped as well as the
local task. Also like libnative, this patch sets up a "bomb" which when it goes
off will restore the state of the world.
bors added a commit that referenced this pull request Jul 30, 2014
Previously both spawning mechanisms were not resilient to task failures which were initiated from the task spawning infrastructure.

Closes #15895
@bors bors closed this Jul 30, 2014
@bors bors merged commit 8643a0d into rust-lang:master Jul 30, 2014
@alexcrichton alexcrichton deleted the task-dont-die branch August 1, 2014 16:52
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 27, 2023
Update Arch Linux package URL in manual.adoc

The old URL returns 404 now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Calling spawn too many times crashes the program
3 participants