Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
In https://github.com/hyperium/hyper/pull/2048/files#diff-8fd688c7233290bc8ae01519ef707f1eR58 the Body was changed to require a
@sfackler Thanks for the more precise link! Being able to safely share a reference between multiple threads includes the possibility of those threads concurrently making use of the reference, which in this case implies reentrancy of the one method offered by said reference.
@seanmonstar Good to know, so my conclusion is that the design of async/await forces Sync in unexpected places. Considering that Sync is “Send for references”, it becomes obvious that the async/await syntax is using these marker types in a way that overapproximates the problem: while it is true that these objects may be sent to other threads, the usual implication of Sync is concurrent access, which is lexically impossible in an async function body. As long as the async scheduler takes care to insert the appropriate optimizer and CPU barriers, an async function body should be regarded as a single-threaded piece of code, so both Send and Sync are not exactly the right abstractions to model what is going on. Do you think it makes sense to discuss this in a different place or forum closer to Rust core? I am rather new in this ecosystem and still learning its ways.