From 9652a42d4562120f52bfb5fe1b82bef3cc99b7ba Mon Sep 17 00:00:00 2001 From: Joe Wilm Date: Mon, 10 Oct 2016 15:44:51 -0700 Subject: [PATCH] fix(conn): Handle remote hangup Not handling this was an issue for keep-alive connections because requests would get assigned to a closed connection and then immediately error. Handling the HUP event makes this situation much less likely. It is still possible however; consider the situation where a HUP arrives while the event loop is busy processing new requests to add. The connection is disconnected, but the HUP hasn't been processed, and a request could be assigned to it. This case is, however, unlikely. --- src/http/conn.rs | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/http/conn.rs b/src/http/conn.rs index cafb04ad..3f486c52 100644 --- a/src/http/conn.rs +++ b/src/http/conn.rs @@ -553,6 +553,13 @@ impl> Conn { } } + if events.is_hup() { + trace!("Conn::ready got hangup"); + let _ = scope.deregister(&self.0.transport); + self.on_remove(); + return ReadyResult::Done(None); + } + // if the user had an io interest, but the transport was blocked differently, // the event needs to be translated to what the user was actually expecting. // @@ -593,7 +600,7 @@ impl> Conn { self.0.on_writable(scope); } - let events = match self.0.register() { + let mut events = match self.0.register() { Reg::Read => EventSet::readable(), Reg::Write => EventSet::writable(), Reg::ReadWrite => EventSet::readable() | EventSet::writable(), @@ -610,6 +617,8 @@ impl> Conn { return ReadyResult::Continue(self); } + events = events | EventSet::hup(); + trace!("scope.reregister({:?})", events); match scope.reregister(&self.0.transport, events, PollOpt::level()) { Ok(..) => {