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

Eliminate unsafety from scheduler operations #6210

Closed
brson opened this issue May 3, 2013 · 4 comments
Closed

Eliminate unsafety from scheduler operations #6210

brson opened this issue May 3, 2013 · 4 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows

Comments

@brson
Copy link
Contributor

brson commented May 3, 2013

The new runtime, scheduler, and I/O types are often accessed through unsafe mutable pointers. There are many interrelated runtime features that expect independent access to mutable task-local or thread-local state, and this is difficult to model safely.

Many of the unsafe features that need to be fixed use functions called unsafe_borrow*, like unsafe_borrow, unsafe_borrow_io, unsafe_borrow_local_services.

More things will need to be passed by value or ~. There are probably useful functional idioms that I'm not familiar with that could help.

bors added a commit that referenced this issue May 21, 2013
r?

Mostly refactoring, and adding some of the remaining types described in #4419.

The [`Local`](https://github.com/brson/rust/blob/3b4ff41511cfaa5e311b03d16b47bf40c117fa2f/src/libcore/rt/local.rs#L17) trait collects some common, often unsafe patterns around task-local and thread-local values. Making all these types safe is largely the aim of #6210.
@emberian
Copy link
Member

Triage bump

@toddaaro
Copy link
Contributor

toddaaro commented Aug 6, 2013

Status bump. The recent scheduler restructuring did a fair bit to eliminate unsafe blocks. In the sched.rs file we are down to unsafe code for the raw context swap, the cleanup job execution, and the "run" operation on the event loop. I think the first two are fundamental and unavoidable, the unsafe fun might be escapable. The unsafe to worry about is now all in the io code.

@catamorphism
Copy link
Contributor

Triage bump -- @brson, is there anything blocking this?

@thestinger
Copy link
Contributor

no longer relevant for the standard libraries due to #17325

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Development

No branches or pull requests

5 participants