Add mochiweb_request:is_closed/1 function #258
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This function can used during long running request callbacks to detect if the client connection is closed.
If the request callback periodically streams data back to the client, the act of writting to the client socket will detect if it is closed or not. However, in cases when no data is sent back, and the client times-out and closes the connection, it may be useful to be able to find out early and stop processing the request on the server.
It turns out there is no easy way to detect if a passive mode socket is closed in Erlang/OTP [1]. Neither one of inet:monitor/1, inet:info/1, inet:getstat/1 work. However, it is possible to do it by querying the TCP state info of the socket. That option available in Linux since kernel 2.4 and on other Unix-like OSes (NetBSD, OpenBSD, FreeBSD and MacOS). Windows also has a tcp info query method however it is not reacheable via the gensockopts(2) standard socket API, so it can't be queried from Erlang's inet:getopts/2 API.
[1] Using the newer socket module it's possible to detect if a socket is closed by attempting a recv with a MSG_PEEK option. However, the regular gen_tcp OTP module doesn't have a recv() variant which takes extra options. In addition, the new socket implementation still feels rather experimental. (It's not the default even in the latest OTP 26 release).