The previous NamedPipeServer doc example seemed to imply that the return
type of `NamedPipeServer::connect()` was a
`Future<Result<some_kind_of_client>>>`, however, `connect()` returns a
`Future<Result<()>>>`. The following line of code reopening the pipe
would shadow the newly connected pipe immediately, making the following
spawned task pointless. Hopefully these changes make it more clear what
should be happening in the example.
The code for `output` indicates that only sets `stdout` and `stderr`,
yet the docs for `stdin` indicated that it too would be set. This seems
like it was just a simple copy/paste typo, so correct `stdin` to note
that it just defaults to `inherit`.
Fixes#6577.
The code that we're removing calls UnsafeCell::with_mut with the
argument `std::mem::drop`. This is misleading because the use of `drop`
has no effect. `with_mut` takes an argument of type
`impl FnOnce(*mut T) -> R`. The argument to the argument function is a
pointer. Dropping a pointer has no effect.
The comment above the first instance of this pattern claims that this
releases some resource. This is false because the call has no effect.
The intention might have been to drop the value behind the pointer. If
this did happen, it would be a bug because the resource (`waker`) would
be dropped again at the end of the function when the containing object
is dropped.
I looked through the history of this code. This code originally called
`with_mut` with the argument `|_| ()`. Calling `with_mut` with an
argument function that does nothing has a side effect when testing with
loom. When testing with loom, the code uses loom's UnsafeCell type
instead of std's. The intention of the code was likely to make use of
that side effect because we expect to have exclusive access here as we
are going to drop the containing object. The side effect is that loom
checks that Rust's reference uniqueness properties are upheld.
To continue to check this, I have only removed the use of `drop` while
keeping `with_mut`. It would be even better to have loom check this
implicitly when UnsafeCell is dropped. I created an issue about this in
loom [1].
Links: https://github.com/tokio-rs/loom/issues/349 [1]
