recv_timeout not triggered when periodic signal interrupts select() on Linux
Development toolkit for Web Services and XML data bindings for C & C++
Brought to you by:
engelen
From time to time sending SOAP request hangs indefinitely even if recv_timeout is set to non-zero value.
Observed on:
Cause:
Proposed solutions:
The problem can probably arise on other places in the code where recv_timeout and send_timeout are used.
Notes:
Last edit: peclik 2013-11-28
Hm, reusing the timeout value after select() is not portable.
The 2.8.17 change is:
Therefore, the tcp_select() function in gsoap 2.8.17 will be changed to allow EINTR only a limited number of times per poll/select before a fatal EINTR error is raised. This can lengthen the poll/select blocking time only by a limited duration, which will be 10 seconds by default.
I'm afraid MAXEINTR solution is not robust enough. Consider EINTR going each 20 ms. Then it will not be possible to send even one SOAP request with 10 attempts; on the other hand in different application parts, the EINTR can trigger with different period (let's say in one case 20ms in other case 1000ms), so it's not possible to set SOAP_MAXEINTR to meaningful value. Also user may not have control of EINTR because of 3rd party libraries and it's not always feasible to disable EINTR.
Also I think this new behavior can break existing applications (while until now it waited very long time, from 2.8.17 it can timeout very soon prematurely because of EINTR).
I think that the only robust and portable solution is to count timeout in tcp_select() itself - i.e. store current time before calling select(), call select(), and then substract time spent from timeout (probably adding new members to the soap structure - bool firstSelectCall and actual timeout).