Re: Socket Poll functionality in case of socket is closed
On Wed, 18 Mar 2020 11:34:00 +0200
"Ravi kumar Veeramally" <email@example.com> wrote:
Hi,If a peer closes TCP connection from its side, it's effectively an
analog of EOF condition. In this case, poll() should return POLLIN.
This will cause a client to issue a recv()/read() call, which will
return 0, and will let a client detect the EOF condition.
This is one of the "most basic" of "not immediately obvious" API
contracts re: sockets and polling. It's definitely something like that,
because quickly looking for normative references in the POSIX standard,
I can't find them, e.g. in
this particular case isn't described (some other "not immediately
obvious" cases are). So, it's a kind of common knowledge, and a lot of
software relies on that behavior (well, it's not possible to write
async socket code without it). If you google for it, you should be able
to find a lot of references.
Note that there's also a POLLHUP flag, behavior of which in regard to
sockets is "less clear" and "somewhat of a gray area".
zsock_poll_prepare_ctx() is an internal function, which uses a special
internal API contract, where particular error codes are used to signal
very specific conditions. -EALREADY is one of such codes. It doesn't
reach public API clients (and doesn't have the same meaning as POSIX
ButRight, to achieve the behavior described above.
I did a simple test with few modifications in echo-client andThat sounds *about* right. Except that POSIX requires EPIPE to be
returned trying to write to a socket with underlying connection closed.
Or to be more exact, with the quote
The socket is shut down for writing, or the socket is
connection-mode and is no longer connected. In the latter case, and if
the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the
MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the
So, if we return ESHUTDOWN, we should change that to EPIPE.
If your mail trails to the ultimate question of "how to detect
peer-closed socket if we called poll with POLLOUT?", then to keep it
a) Hmm, I don't have an answer right away, though I bet I used to
consider it (likely outside Zephyr context).
b) I bet that's where POLLHUP return status kicks in.
c) In all cases like that, where we can't "extract" normative behavior
description from POSIX, we should check and follow the behavior of a
well-know implementation, and that's definitely Linux.
Please don't hesitate to cc: me on mails like this, I may sometimes not
check the mailing list for a few days.
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog