You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 7, 2019. It is now read-only.
Running the following test program hangs and doesn't notice that the client has closed the write side of the TcpStream:
#![feature(futures_api, async_await, await_macro)]use std::{io, net::IpAddr};use futures::{StreamExt, io::{AsyncReadExt,AsyncWriteExt}};use romio::TcpListener;use romio::TcpStream;fnmain(){
futures::executor::block_on(async{let ip:IpAddr = "127.0.0.1".parse().unwrap();letmut listener = TcpListener::bind(&(ip,0).into()).unwrap();let port = listener.local_addr().unwrap().port();letmut incoming = listener.incoming();let(_rx,mut tx) = await!(TcpStream::connect(&(ip, port).into())).unwrap().split();let(mut rx, _tx) = await!(incoming.next()).unwrap().unwrap().split();println!("Connection established");println!("Closing tx");await!(tx.close()).unwrap();println!("Wait for server to notice connection was closed...");letmut byte = [0];let res = await!(rx.read_exact(&mut byte));assert!(res.is_err());assert_eq!(res.unwrap_err().kind(), io::ErrorKind::UnexpectedEof);})}
By adding in a wrapper around the clients TcpStream that implements poll_close to call shutdown(Shutdown::Write) the server notices that the client has closed the TCP connection
For some reason in the linked Tokio issue they don't want to apply this change to TcpStream itself, I can't see any reason not to just change it though.
The text was updated successfully, but these errors were encountered:
(One thing I'm not sure about with that wrapper is whether TcpStream::shutdown can return WouldBlock, if so then it would need to hook into the reactor somehow).
@Nemo157 I feel like I've run around into a version of this in Romio too (though not 100% sure it's the exact same thing). Iirc at the time it was cited that this was in line with std's TcpStream behavior.
Def agree having a way forward to prevent hanging would be excellent. I've heard of more people struggle with the reader APIs around Tcp.
I'm running into this as well. AFAICT the behavior is not in line with the standard library. On the standard library TcpStream you can call shutdown which will allow the reading end to see the EOF. Dropping also works.
On the romio TcpStream only dropping works. Calling close will leave the reading side hanging until the sender is actually dropped. I think this is counter intuitive.I feel that on futures primitives calling close usually returns None on the reading end (channels, Stream/Sink, ...).
At the least, I think the behavior should be documented at TcpStream and at the close method.
Is there a reason we don't call shutdown in PollEvented::close? It currently does nothing. I think we should call shutdown from mio::TcpStream here with Shutdown::Write.
I can file a PR if that sounds like the solution.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is very similar to tokio-rs/tokio#852.
Running the following test program hangs and doesn't notice that the client has closed the write side of the
TcpStream
:By adding in a wrapper around the clients
TcpStream
that implementspoll_close
to callshutdown(Shutdown::Write)
the server notices that the client has closed the TCP connectionFor some reason in the linked Tokio issue they don't want to apply this change to
TcpStream
itself, I can't see any reason not to just change it though.The text was updated successfully, but these errors were encountered: