unistd: raise SIGPIPE signal on write() EPIPE error

[Maxez]

DO NOT MERGE THIS YET, IT'S JUST A PROPOSED SOLUTION

EPIPE and SIGPIPE in write() as described by OpenGroup:

[EPIPE]
An attempt is made to write to a pipe or FIFO that is not open for reading by any process, or that only has one end open. A SIGPIPE signal shall also be sent to the thread.
[EPIPE]
A write was attempted on a socket that is shut down for writing, or is no longer connected. In the latter case, if the socket is of type SOCK_STREAM, a SIGPIPE signal shall also be sent to the thread.

Things to consider/change:

• Should every write() EPIPE error generate SIGPIPE signal?
  No. As mentioned above writing to shut down SOCK_DGRAM(UDP) socket should return EPIPE error without SIGPIPE signal.
• Should SIGPIPE be sent to the writing thread or process (all process threads)?
  As mentioned above SIGPIPE should be sent to the writing thread only.

Description

Changed write() to raise SIGPIPE signal on EPIPE error.

Motivation and Context

Fixes phoenix-rtos/phoenix-rtos-project#166
JIRA: RTOS-84

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: ia32-generic.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[nalajcie]

Please note that SIGPIPE might be also a result from operations on sockets (sent, sendto, sendmsg could also return EPIPE and generate SIGPIPE signal):

[agkaminski]

@nalajcie if we add such wrapper for send, sendto and sendmsg will this be ok? It's a simple solution and fits nicely in our architecture, question is - is it enough?

[nalajcie]

I've found some more insights:
https://riptutorial.com/posix/example/17424/handle-sigpipe-generated-by-write---in-a-thread-safe-manner

Seems that on MacOS / BSD there is a socket option (SO_NOSIGPIPE) to disable signals for particular socket which would impair the current approach (You would need to call additional syscall for each write()). On Linux tere is MSG_DONTWAIT flag for send / sendmsg (and socket option is not supported) so this approach might be good enough - we probably need to decide which API we would like to support. The current approach doesn't sit well with me because of additional syscall which in kernel would be a no-op (most complex programs will have SIGPIPE ignored) - but I agree that it fits with our current approach.

On a side note - it's written in the link provided that POSIX-2004 requires us to send signal to the correct thread (not process) which is something we should take into the consideration in the future.

[agkaminski]

@nalajcie About sending signal to the right thread - our raise already does this - it send a signal specifically to the thread that called raise, so we're covered here. It is required by POSIX for raise to behave this way anyway.

[nalajcie]

@nalajcie About sending signal to the right thread - our raise already does this - it send a signal specifically to the thread that called raise, so we're covered here. It is required by POSIX for raise to behave this way anyway.

Oh, that's great! I don't know how advanced our signal implementation is, do we support per-thread signal masking also (phtread_sigmask as in https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_sigmask.html)?