Version: 1
-Previous: f3d799efacf6fee8524de608a66c97b38f45991d
-Head: 42a1528fa6acaa7141eac1e63bc32de0159760a8
+Previous: ba3a2e591cb3f5c8aa45f85540c1bfeaedd8f7d8
+Head: fa37ec50248e8bc04a9a6662dcd2183bfc93af54
Applied:
- pre-udp: 650d48956903637edc5565882454ce1d0c179375
- refresh-temp: 42a1528fa6acaa7141eac1e63bc32de0159760a8
+ pre-udp: fa37ec50248e8bc04a9a6662dcd2183bfc93af54
Unapplied:
resv-rs-len: 7b6ff5c4894f54b221d877adcd709795dffb2fe9
rs-target-sgl: 7a07c80f2242e80c076dcf3ec6bb4c94626b284f
Support for existing UDP applications is done via the rspreload
library. However, when the preload library is loaded, socket
calls used by rsockets get intercepted and converted into
-rsocket calls. The preload library was able to handle this
+rsocket calls.
+
+The preload library was able to handle this for TCP rsockets
+by using a per thread variable and checking for recursive calls
+coming from rsockets back into the preload library. The preload
+library would direct such calls to the real socket calls.
+
+The problem is more complex for UDP rsockets, which can invoke
+socket calls from an internal rsocket thread. The result is that
+the preload library intercepts socket calls that originate from
+the rsocket library which are not recursive.
+
+Although, this is really a problem with the preload library,
+the simplest solution is for rsockets to fully initialize the
+library when allocating the first rsocket, versus deferring
+initialization until required. The preload library can then
+detect the recursive calls.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
+++ /dev/null
-Bottom: 1d1da945e49647331f04f82a45cc353e9541a6ae
-Top: 1d1da945e49647331f04f82a45cc353e9541a6ae
-Author: Sean Hefty <sean.hefty@intel.com>
-Date: 2013-01-11 15:24:00 -0800
-
-Refresh of pre-udp
-
----
-
-