GSocket needs a plan with respect to the foul accursed evil that is SIGPIPE.

There is really only one thread-safe, sane, portable possibility, and that is to call "signal (SIGPIPE, SIG_IGN);" from g_socket_class_init(). This is what libsoup, ORBit, and D-Bus all do currently, and gspawn is already smart enough to undo it when launching a new process.

The non-thread-safe possibility is to temporarily ignore the signal only around calls to send() and sendmsg(). However, this would require some sort of locking or atomic refcounting to deal correctly with the case where g_socket_send() was called simultaneously in two different threads. (And even then would still only work as long as no one else was mucking with the SIGPIPE handler.)

The non-sane possibility is to have a signal handler instead of using SIG_IGN, and having some static volatile flags that we'd modify with g_atomic_* from within g_socket_send(), g_socket_send_message(), and the signal handler, and cleverly make it so that if we get a SIGPIPE which is then followed by an EPIPE in one of those methods, then we ignore it, but if we get a SIGPIPE while we're not in one of those methods or else we get a SIGPIPE but then the send()/sendmsg() call does not return EPIPE, then we let the process be killed.

The non-portable possibility is to use MSG_NOSIGNAL or SO_NOSIGPIPE on the platforms that support one or the other (Linux, FreeBSD, and OS X). But that leaves Solaris and the other BSDs broken.