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.

Sign up for GitHub

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

Jump to bottom

task/spawn.rs should really be task/taskgroup.rs or rt/taskgroup.rs #8318

Closed
bblum opened this issue Aug 5, 2013 · 1 comment · Fixed by #10603
Closed

task/spawn.rs should really be task/taskgroup.rs or rt/taskgroup.rs #8318

bblum opened this issue Aug 5, 2013 · 1 comment · Fixed by #10603
Labels
A-concurrency Area: Concurrency related issues. C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@bblum
Copy link
Contributor

bblum commented Aug 5, 2013

Maybe? Maybe not? It's gotten its implementation details pretty intertwined with rt/task.rs and rt/kill.rs by now.

But many of the test cases in it should actually be in task/mod.rs (and the linked failure tests in task/mod.rs should be in it...).

Also also I think the pub mod spawn declaration in task/mod.rs should be private?
@brson
Copy link
Contributor

brson commented Aug 5, 2013

rt::taskgroup. The spawn module is probably public because of some resolve bug. Should be private.

@alexcrichton alexcrichton mentioned this issue Nov 22, 2013
Merged
bors added a commit that referenced this issue Nov 25, 2013
@bors
auto merge of #10603 : alexcrichton/rust/no-linked-failure, r=brson
2cc1e16 
The reasons for doing this are:

* The model on which linked failure is based is inherently complex
* The implementation is also very complex, and there are few remaining who
  fully understand the implementation
* There are existing race conditions in the core context switching function of
  the scheduler, and possibly others.
* It's unclear whether this model of linked failure maps well to a 1:1 threading
  model

Linked failure is often a desired aspect of tasks, but we would like to take a
much more conservative approach in re-implementing linked failure if at all.

Closes #8674
Closes #8318
Closes #8863
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-concurrency Area: Concurrency related issues. C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove linked failure from the runtime alexcrichton/rust
2 participants
@brson @bblum