While testing this library, I found that, if the STOMP server is disconnected or disappears for some reason, the socket which the library sets up and uses is silently disconnected. If the application employing the library issues a write, in this circumstance, the application silently quits. This is due to the use of the POSIX write() function, which, by POSIX design, forces the invoking application to quit rather than lingering around when the output is no longer needed.
Instead, a very simple solution, is to replace the use of write() with the functionally equivalent POSIX function send(), which allows to specify flags, one of which is MSG_NOSIGNAL. This prevents SIGPIPE from being raised when the connection is broken, and puts the onus on the caller to detect that the write failed, which is, in fact how the function using this routine appeared to attempt to handle.
While testing this library, I found that, if the STOMP server is disconnected or disappears for some reason, the socket which the library sets up and uses is silently disconnected. If the application employing the library issues a write, in this circumstance, the application silently quits. This is due to the use of the POSIX write() function, which, by POSIX design, forces the invoking application to quit rather than lingering around when the output is no longer needed.
Instead, a very simple solution, is to replace the use of write() with the functionally equivalent POSIX function send(), which allows to specify flags, one of which is MSG_NOSIGNAL. This prevents SIGPIPE from being raised when the connection is broken, and puts the onus on the caller to detect that the write failed, which is, in fact how the function using this routine appeared to attempt to handle.