Version: 1
-Previous: 0d572b57816fc1fe454532879cf611b606f1b319
-Head: f9d068e74c866f272d486ab8b9018e19755fc00d
+Previous: 5d990e8f1cc7496d9e5ba75435964230a8ba9539
+Head: f6e62054b50421dc41a3a2a3734dd3f656ac1b7c
Applied:
real-close: 3409f8d6af187d25c63a5d1f8ee8bff5f14555e2
dup2: ca5813e7cf95dee5933fc417e4a34d26f2b01824
oobinline: ac51c1095f505373a6ec54b8f1d990259fb34d97
- fork-connect: b0f890f94a7a9af571f390e1cc5885474d934212
- refresh-temp: f9d068e74c866f272d486ab8b9018e19755fc00d
+ fork-connect: f6e62054b50421dc41a3a2a3734dd3f656ac1b7c
Unapplied:
dbg-out: 04273ee712db4d53efb390462c1b738bb54a57df
fstat: a62c653906870422edef5f6388dac9f76c953e35
blocked waiting for the server to accept the connection,
which it will never do.
-Fix this by deferring the fork connection handling until the
-first socket call after connect.
+To handle this case, we have the active side follow the same
+rule as the server side and defer establishing the rsocket
+connection until the user calls the first data transfer routine.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
+++ /dev/null
-Bottom: 869244971263f9cd4426b0428f1505bf77030a32
-Top: 869244971263f9cd4426b0428f1505bf77030a32
-Author: Sean Hefty <sean.hefty@intel.com>
-Date: 2012-08-13 15:55:10 -0700
-
-Refresh of fork-connect
-
----
-
-