tree c9cecd3ec613119b195f1c499edcb3548c30a5c6
parent 3697fc61ed4e9cc199cb98cc3acc4c752be933ff
author Barret Rhoden <brho@cs.berkeley.edu> 1513704019 -0500
committer Barret Rhoden <brho@cs.berkeley.edu> 1513795028 -0500

net: Report conversation-wide info in Qdata stats

select() and other users of stat will check the Qdata file, but not the
other files such as Qlisten or possibly Qctl.

It's reasonable to merge the 'Connected' status with Qdata
readability/writability.  If a conversation is not connected, then the user
can't read or write yet, even if the qio queues have room/data.  This
applies for protocols that have a connect method, like TCP and also UDP.

This pops up as an issue for apps that want to tap the ctl FD for
non-blocking connect() calls.  They actually select on the socket, which
ends up being an epoll on the data FD, listen FD, and ctl FD.  However,
thanks to the Linux buggy epoll behavior, if you start epolling on a data
FD and the FD is ready, you'll get an epoll event.  An epoll/select on any
of the Rock FDs looks like the socket is ready - in this case writable.
That looks to the app as if select fired for a non-blocking connect.
Whoops!

Similarly, we could have situations where select() stats a Qdata instead of
a Qlisten.  Reporting on Qlisten for Qdata isn't ideal, but the socket
stuff should never use a socket for both listening and data at the same
time.  I think.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>