tipc: introduce non-blocking socket connect
authorYing Xue <ying.xue@windriver.com>
Thu, 29 Nov 2012 23:51:19 +0000 (18:51 -0500)
committerPaul Gortmaker <paul.gortmaker@windriver.com>
Fri, 7 Dec 2012 22:23:21 +0000 (17:23 -0500)
commit584d24b3960e4c877fc623214815f278708f127c
tree7270e28a6d3df9f46cb096a6a9f640fa75e00b94
parent7e6c131e1568dcc2033736739a9880dce1976886
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>
net/tipc/socket.c