In case an application successfully issues xcm_send() on a TLS/BTLS connection, and continues to go into select(), depending on what condition is set (with xcm_await()), the application may go directly out of select()/epoll_wait()/poll(), since XCM has put an always-active fd in the socket's epoll instance.
The reason for this BTLS transport behavior is indeed to force a wake-up, and to have the application issue whatever operation it desires (i.e., whatever the condition reflects). In the above-mentioned scenario, the app would call xcm_receive() and likely get a -1 back with errno set to EAGAIN. The reason XCM trigger this behavior is to get OpenSSL to answer the question "what should one wait for on the fd, in order to perform a SSL_write() or SSL_read a particular SSL object". There is no other way in OpenSSL to retrieve the condition to wait for to do an SSL_read() than to call SSL_read() and observe the result.
This is less than ideal from a performance perspective. The "wake-up" is likely not putting the thread to sleep, but a long series of syscalls are needed.
Investigate if this behavior can be improved and "bouncing" to select()/epoll_wait()/poll() can be avoided.
In case an application successfully issues xcm_send() on a TLS/BTLS connection, and continues to go into select(), depending on what condition is set (with xcm_await()), the application may go directly out of select()/epoll_wait()/poll(), since XCM has put an always-active fd in the socket's epoll instance.
The reason for this BTLS transport behavior is indeed to force a wake-up, and to have the application issue whatever operation it desires (i.e., whatever the condition reflects). In the above-mentioned scenario, the app would call xcm_receive() and likely get a -1 back with errno set to EAGAIN. The reason XCM trigger this behavior is to get OpenSSL to answer the question "what should one wait for on the fd, in order to perform a SSL_write() or SSL_read a particular SSL object". There is no other way in OpenSSL to retrieve the condition to wait for to do an SSL_read() than to call SSL_read() and observe the result.
This is less than ideal from a performance perspective. The "wake-up" is likely not putting the thread to sleep, but a long series of syscalls are needed.
Investigate if this behavior can be improved and "bouncing" to select()/epoll_wait()/poll() can be avoided.