Expose hangup events from TcpStream?

[sfackler]

I'm working on a server that processes fairly expensive requests. It's common for a client to give up waiting on the response and close the connection, but the server will continue working and only fail out after trying to write the it back. It'd be great if the server could be somehow notified that the stream's hung up so it can stop doing work immediately.

It's not totally clear to me how this would actually be exposed, but the ideal behavior would allow me to get a future that'd resolve after a hangup that I could select on against the handler logic.

[alexcrichton]

Right now the "hup signal" is routed to being readable as I believe HUP means that read will always be ready with 0 bytes, will that work in this case?

[carllerche]

The argument could be that there is still buffered data on the socket that hasn't been read yet (because the server isn't ready to process) but then a HUP arrives...

That said, I don't think getting HUP accurately is a portable feature.

[sfackler]

I'm fine with some platforms not being able to report a HUP.

I don't think read readiness will work - I can't be constantly waiting on a read since the request handler may not be ready for more data.

[carllerche]

I'd say that this is definitely worth thinking about for the next iteration of Tokio. @sfackler have you commented re: this on the RFC?

[sfackler]

Nope, I will do so though!

[alexcrichton]

@sfackler oh FWIW this may have been in the meantime, there's now a poll_ready funciton so you can explicitly check for HUP