Closed mogar closed 4 years ago
Understood, as a workaround you can probably just send "0" for the send() flags parameter. I can try removing it from the codebase but I am guessing SIGPIPE will cause issues with the signal handling in cFE. (Hard to test, too.)
Longer-term, OSAL will have a network interface that supports TCP and UDP and will hopefully abstract away platform-specific issues.
Would the current OSAL Socket API's work? See osal/src/os/inc/osapi-os-net.h (supports DATAGRAM and STREAM).
Indeed, the current OSAL APIs are abstracting the TCP and UDP. This should work for SBN.
That being said, the current OSAL is also by default blocking all signals except INT/ABRT and the errors, so PIPE would be blocked by default too.
Indeed, the current OSAL APIs are abstracting the TCP and UDP. This should work for SBN.
That being said, the current OSAL is also by default blocking all signals except INT/ABRT and the errors, so PIPE would be blocked by default too.
Copy, I'll create a separate ticket to move to using OSAL and, for now, just remove the MSG_NOSIGNAL flag.
See ticket #13 for the OSAL implementation ticket.
Changes have been pushed to close #13, I would appreciate a re-test against VxWorks if you get a chance, @mogar . Thanks!
Won't be able to test until the new year. Hope you can wait :)
Confirm that this is working for me. Thanks!
Line 339 of sbn_tcp_if.c references MSG_NOSIGNAL, which doesn't seem to exist for VxWorks. I'm using the VxWorks target cmake file from here: https://github.com/nasa/cFE/blob/master/cmake/sample_defs/toolchain-ppc-vxworks6.9.cmake
SBN version 1.9, cloned from master.