The OS_recvfrom() error codes use the underlying socket error codes. 4 is an interrupted system call:
Berkeley description: An asynchronous signal (such as SIGINTor SIGQUIT) was caught by the process during the execution of an interruptible function. If the signal handler performs a normal return, the interrupted function call will seem to have returned the error condition.
WinSock description: NOT same as Berkeley, but analogous. In WinSock it means a blocking operation was interrupted by a call to WSACancelBlockingCall.
(hat-tip to http://www.sockets.com/err_lst1.htm)
Generally I see the OS_recvfrom() errors from Windows.
This is something "low level" and so underneath DDS. If it is a BE reliability qos, the data is lost. If it is a Reliable reliability, the dropped sequence number will be noted and repaired via the normal method, assuming your history is deep enough.
Some of our customers have worked around this error by disabling the signals during Participant and DataReader creation:
Block all signals before calling the three API calls that create DDS threads (create_participant(), enable(), create_datareader() ).
Unblock the signals right after the API calls return. Signals only have to be blocked/un-blocked for the create_datareader() call if the subscriber is using multicast for user data.
If you have access to the code that produces the signals (e.g., in the case of signals produced by timers), the following approach is also a possible workaround:
Modify the signal mask in the main routines to block the real-time signal used by the timers. This masks that signal off in all of the threads created within the process.
Then modify the threads created by the timers to allow only that signal.
Also, would this error keep a message from being received?
The OS_recvfrom() error codes use the underlying socket error codes. 4 is an interrupted system call:
Berkeley description: An asynchronous signal (such as SIGINTor SIGQUIT) was caught by the process during the execution of an interruptible function. If the signal handler performs a normal return, the interrupted function call will seem to have returned the error condition.
WinSock description: NOT same as Berkeley, but analogous. In WinSock it means a blocking operation was interrupted by a call to WSACancelBlockingCall.
(hat-tip to http://www.sockets.com/err_lst1.htm)
Generally I see the OS_recvfrom() errors from Windows.
This is something "low level" and so underneath DDS. If it is a BE reliability qos, the data is lost. If it is a Reliable reliability, the dropped sequence number will be noted and repaired via the normal method, assuming your history is deep enough.
Thanks for the information.
Hi,
Some of our customers have worked around this error by disabling the signals during Participant and DataReader creation:
If you have access to the code that produces the signals (e.g., in the case of signals produced by timers), the following approach is also a possible workaround: