After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583001 - SIGPIPE (grr!)
SIGPIPE (grr!)
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: network
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2009-05-18 01:00 UTC by Dan Winship
Modified: 2009-05-20 10:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Ignore SIGPIPE when using GSocket (1.53 KB, patch)
2009-05-18 01:01 UTC, Dan Winship
none Details | Review

Description Dan Winship 2009-05-18 01:00:17 UTC
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.
Comment 1 Dan Winship 2009-05-18 01:01:11 UTC
Created attachment 134842 [details] [review]
Ignore SIGPIPE when using GSocket
Comment 2 Alexander Larsson 2009-05-20 10:33:34 UTC
I already do this in GVfs too... Applied.