Why does Body need to be Sync?

[rkuhn]

In https://github.com/hyperium/hyper/pull/2048/files#diff-8fd688c7233290bc8ae01519ef707f1eR58 the Body was changed to require a Sync bound. This trickles down into Body::wrap_stream, which now requires the Stream to be Sync as well. A Stream struct basically is the description of a task out of which elements can be pulled. Requiring this task to be Sync amounts to saying that the poll_next function needs to be reentrant, but that runs counter to its signature which promises a &mut self reference (i.e. an exclusive reference). Somewhere in here something is broken, could you enlighten me exactly where the breakage lies?

[sfackler]

That is not the commit that made the change, this is: 4441372.

Reentrancy is not discussed in the definition of Sync that I'm aware of. The standard definition has to do with safe concurrent access to a shared reference to a type.

[seanmonstar]

The reason is described in the comment, pointing at rust-lang/rust#57017.

Without the requirement, this code fails to compile in a very confusing way:

match res.status() {
    StatusCode::OK => {
        let _chunk = res.body_mut().data().await;
    },
    _ => (),
}

[rkuhn]

@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.

[seanmonstar]

You could bring it up in the issue I referenced, or if it only loosely matches, try internals.rust-lang.org.

[rkuhn]

done at internals, thanks!