Lorenz Bauer wrote:
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.
Feel free to submit a patch to the ITS, according to
Since it seems this is a pretty small change, I suggest your IPR notice should
place your changes into the public domain.
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 . Go has some
additional trickery when dealing with stdin and stdout, so ignoring
SIGPIPE for the whole process is undesirable (details in ).
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/