ipc_core: Blob_stream_mq_sender (MQ pipe) lacks equivalent of broken-pipe type error

[ygoldfeld]

Filed by @ygoldfeld pre-open-source:

This issue does not (technically at least) violate any concept (namely Blob_sender/receiver), and there are likely plenty of mitigating facts that make it not matter super-much, but nevertheless it is a "miss":

Consider a Native_socket_stream (Unix domain socket-based bidirectional pipe). The way to gracefully end a connection is to [async_*]end_sending() on one side; the other side will receive a special error indicating this happened, once it has received all the preceding messages. This is the equivalent of a socket EOF (recv() in Berkeley sockets returns 0). Normally users should use this and/or their own user-space end-of-convo message. However, if the user simply destroys a peer N_s_s, the other N_s_s will sooner or later (investigate when exactly, I always forget these exact semantics without shutdown()) emit an error; whether it's EOF or broken-pipe.

By contrast, unless I am forgetting something, if one destroys Blob_stream_mq_sender – without *end_sending() – Blob_stream_mq_receiver will not be informed. Internally this is simply because the underlying MQ (whether POSIX or bipc) continues to exist, even though that dtor removes the named MQ from file system. The handle is still valid, so the MQ remains.

We should somehow signal this event. As to specifics:

• It could be a new CONTROL message type. Could even just send the CONTROL message of type END_SENDING (the FIN-like guy).
• Try to mimic what Unix domain sockets do if one just close()s a side, particularly if the socket is at that time write-blocked (buffer full) and also not write-blocked but with non-empty buffer; does the close() trigger some kind of immediate RST-ish thing? Or does it simply mimic a FIN-type thing (graceful close)? Might require a bit of investigation. Anyway do something similar in corner cases, to the extent possible.
• On the other hand don't worry too much about those; this should be a best-effort solution all in all.

A main mitigation is that user protocols should be written with graceful closing built in, and we provide full support for that already ([async_]end_sending() and the associated error on the receiver). Other mitigations include the fact that the underlying session in many cases will end too, so user would end all related channels if properly coding; the session uses a UDS for the session master channel, so even an abrupt ending will be signaled without a problem. Plus if the Channel (if any) with the blob-stream-MQ pipe(s) has a UDS pipe too, that one will signal the end of the channel.

None of those is 100%, so we should give a decent effort for this.