←back to thread

517 points bkolobara | 1 comments | | HN request time: 0.001s | source
Show context
Spivak ◴[] No.45041771[source]
How do you encode the locking issue in the type system, it seems magical? Can you just never hold any locks when calling await, is it smart enough to know that this scheduler might move work between threads?
replies(5): >>45041806 #>>45041833 #>>45041852 #>>45041891 #>>45041898 #
jvanderbot ◴[] No.45041806[source]
Yes Rust has ways of verifying single access to locks through the borrow checker and lifetimes.
replies(1): >>45041860 #
Spivak ◴[] No.45041860[source]
Well yes but this seems more complicated. If the code was executed on a single thread it would be correct. The compiler somehow knows that await might move the work to another thread in which the code would still be correct if it weren't for the pesky undefined behavior. At all points it seems like it would be single access and yet it catches this.
replies(3): >>45042126 #>>45042240 #>>45042247 #
1. 0x1ceb00da ◴[] No.45042126[source]
An async function call returns a future which is an object holding the state of the async computation. Multithreaded runtimes like tokio require this future to be `Send`, which means it can be moved from one thread to another. The future generated by the compiler is not Send if there is a local variable crossing an await boundary that is not `Send`.