Hello Hallvard, List,
I'd like to propose explicitly ignoring SIGPIPE in the copy thread via pthread_sigmask, and returning EPIPE to the caller instead.
This is a change that makes little sense in the C world, since the caller can simply adjust the sigmask before calling the function (which is indeed what the utilities do). However, this amount of control is not always given, e.g. when using LMDB from Go (which is what I am doing).
Due to the way the Go runtime works, using mdb_env_copyfd2 with CP_COMPACT on a pipe or a network connection will abort the whole process with SIGPIPE if the reading end of the fd is closed prematurely. The details why this happens are in [1]. Go has some additional trickery when dealing with stdin and stdout, so ignoring SIGPIPE for the whole process is undesirable (details in [2]).
I understand that you might be reluctant to change the behaviour due to the constraints of a different runtime. However, I think that even in the C world it is surprising that calling a library function can abort your process.
What are your thoughts regarding this? I think the code changes would be small, and the API would not change for consumers of the library.
1: https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG 2: https://golang.org/pkg/os/signal/#hdr-SIGPIPE
Best, Lorenz