Tasks should not hold a ref to their parent

[brson]

Tasks are reference counted and every child task holds a reference to its parent until the child is destroyed or becomes unsupervised. This could have many bizarre consequences, keeping lots of resources around long after they should be released.

[nikomatsakis]

I am not sure... I rather think that parents with outstanding supervised children should not be considered dead until those children are dead (in particular, they should not send out their join message, because even if they succeed, they may yet fail due to failure propagation). Of course this doesn't mean that the parent's resources shouldn't be collected, but the child will probably need sort of ref.

[brson]

Yes, failure propagation is the reason this situation exists. Needs some deep thinking all around.

See also #1189 and #1078

[brson]

I should point out that the reason I brought this up now is because tasks keep their schedulers alive, so now we can have zombie tasks holding onto entire threads.

[bblum]

hope it's ok if I take this out from under you. the new linked failure should subsume this.

[bblum]

Fixing this bug will make this no longer segfault.

const generations: uint = 1024+256+128+49;

fn child_no(x: uint) -> fn~() {
    ret || {
        if x < generations {
            task::spawn(child_no(x+1));
        }
    }
}

fn main() {
    task::spawn(child_no(0));
}

[bblum]

Also, after fixing this, I believe nothing will ever refcount a task apart from itself (well, its sched_loop is the one that derefs it, but same thing)?

I'll leave the refcount in in case it's needed for work stealing, I think. It's an atomic operation but it won't cost anything because it never contends.

[bblum]

Note: #2671 required making use of the reference count, so it still isn't deadcode.

[brson]

I'm glad to see this issue fixed.