summaryrefslogtreecommitdiff
path: root/net/caif
diff options
context:
space:
mode:
authorYing Xue <ying.xue@windriver.com>2012-11-29 18:51:19 -0500
committerPaul Gortmaker <paul.gortmaker@windriver.com>2012-12-07 17:23:21 -0500
commit584d24b3960e4c877fc623214815f278708f127c (patch)
tree7270e28a6d3df9f46cb096a6a9f640fa75e00b94 /net/caif
parent7e6c131e1568dcc2033736739a9880dce1976886 (diff)
tipc: introduce non-blocking socket connect
TIPC has so far only supported blocking connect(), meaning that a call to connect() doesn't return until either the connection is fully established, or an error occurs. This has proved insufficient for many users, so we now introduce non-blocking connect(), analogous to how this is done in TCP and other protocols. With this feature, if a connection cannot be established instantly, connect() will return the error code "-EINPROGRESS". If the user later calls connect() again, he will either have the return code "-EALREADY" or "-EISCONN", depending on whether the connection has been established or not. The user must have explicitly set the socket to be non-blocking (SOCK_NONBLOCK or O_NONBLOCK, depending on method used), so unless for some reason they had set this already (the socket would anyway remain blocking in current TIPC) this change should be completely backwards compatible. It is also now possible to call select() or poll() to wait for the completion of a connection. An effect of the above is that the actual completion of a connection may now be performed asynchronously, independent of the calls from user space. Therefore, we now execute this code in BH context, in the function filter_rcv(), which is executed upon reception of messages in the socket. Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> [PG: minor refactoring for improved connect/disconnect function names] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Diffstat (limited to 'net/caif')
0 files changed, 0 insertions, 0 deletions