This repository has been archived by the owner on Dec 9, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@homunkulus r+ |
📌 Commit 69a7ffd has been approved by |
💔 Test failed - status-travis |
Network error @homunkulus retry |
this commit allow lock-less memory safe data sharing between the "main" context, the `setup` / `loop` functions, and cloud functions through the `Resource` abstraction. `Resource`s are global variables that are safe to access from different contexts. Safety is enforced in two ways: Single context memory safety: The `Resource.access{,_mut}` methods take a "context" token, `App` or `Cloud`, to preserve Rust borrowing rules: only one mutable reference (`&mut -`) OR several shared references (`&-`) may exist at any given time. This rule prevents pointer invalidation. This is the inked of problem we prevent at compile time: ``` fn loop_(ref mut app: App) { static OWNED: Resource<Option<i32>> = Resource::new(Some(0)); let owned = OWNED.access(app); let shared_ref: &i32 = owned.as_ref().unwrap(); let mut_ref = OWNED.access_mut(app); // ~^ compile error (`app` has been frozen by the `shared_ref` borrow) // `OWNED` changed to `None`. `shared_ref` has been invalidated *mut_ref.as_mut().unwrap() = None; let bad = *shared_ref; } ``` Memory safety during preemption: If SYSTEM_THREAD is not enabled, which is our case, then cloud functions can *only* preempt the main context, `loop` / `setup`, when the `App.delay_ms` method is called. To ensure no pointer invalidation occurs in that case a `App.delay_ms` call won't compile if there are outstanding borrows to resources in the current context. This is the kind of problem we prevent at compile time: ``` rust static SHARED: Resource<Option<i32>> = Resource::new(Some(0)); fn loop_(ref mut app: App) { let shared = SHARED.access(app); let shared_ref: &i32 = shared.as_ref().unwrap(); // `task` preempts this context during this delay app.delay_ms(100); //~^ compile error (`app` has been frozen by the `shared_ref` borrow) // `shared_ref` would have been invalidated at this point because `SHARED` // now contains a `None` variant let bad = *shared_ref; } fn task(_: String, ref mut cloud: Cloud) { // "empties" the SHARED resource *SHARED.access_mut(cloud) = None; } ```
@homunkulus r+ |
📌 Commit ddbfd92 has been approved by |
☀️ Test successful - status-travis |
Awesome! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this commit allow lock-less memory safe data sharing between the "main" context,
the
setup
/loop
functions, and cloud functions through theResource
abstraction.
Resource
s are global variables that are safe to access from differentcontexts. Safety is enforced in two ways:
Single context memory safety: The
Resource.access{,_mut}
methods take a"context" token,
App
orCloud
, to preserve Rust borrowing rules: only onemutable reference (
&mut -
) OR several shared references (&-
) may exist atany given time. This rule prevents pointer invalidation. This is the kind of
problem we prevent at compile time:
Memory safety during preemption: If SYSTEM_THREAD is not enabled, which is our
case, then cloud functions can only preempt the main context,
loop
/setup
, when theApp.delay_ms
method is called. To ensure no pointerinvalidation occurs in that case a
App.delay_ms
call won't compile if thereare outstanding borrows to resources in the current context. This is the kind of
problem we prevent at compile time:
cc @dbrgn the function and variable examples are now fully safe