I still don't get why CLOSE_WAIT exists at all, i.e. why kernel can't handle this transition.
-
-
there may still be data waiting to be sent. It must happen when a duplex channel is treated as simplex.
2 replies 0 retweets 1 like -
Whether there is data waiting to be sent is a function of the socket state, tho, not whether fd is closed.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @mfukar and
The app can't send new data on a CLOSE_WAIT socket, so doesn't seem to justify exposing this state to the app.
1 reply 0 retweets 0 likes -
The FIN means the client has stopped sending. It doesn't imply that the client can't receive.
2 replies 0 retweets 0 likes -
Oh so it's just a one-way shutdown()? That doesn't seem to match the article's analysis though.
2 replies 0 retweets 0 likes -
I know little more than the article, but it checks out to me. The article problem is asymmetric timeout/state.
1 reply 0 retweets 0 likes -
Well in the article the peer close()d socket rather than just shutdown(SHUT_WR). So why can't kernel reap it?
1 reply 0 retweets 0 likes -
no, wait, the client side is reaped. The server side did NOT call close() (root cause), and leaked, and dangled
1 reply 0 retweets 0 likes -
Right. I'm saying, if the peer (client) fully closed the socket, I can't see any motive for CLOSE_WAIT.
2 replies 0 retweets 0 likes
There's nothing useful the app can do with the socket, so the kernel could (should?) reap it itself.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.