justincohen was asking about SIGPIPE for chrome-for-iOS, perhaps this was the issue.

Yep, I landed the fix/workaround in Chrome for iOS, and I also asked if perhaps CrNet/Cronet should do the same.  I'm assuming there's no reason to revert the CL mentioned in  OP if and when SIGPIPE is disabled in CrNet, right?

That is correct. We will mask SIGPIPE in "CrNet.mm" file. That will affect CrNet only.

Any objections to leaving https://chromereviews.googleplex.com/438667013 in place, or should we rely on the ios/crnet/CrNet.mm change only and revert 438667013?

I'd prefer to keep 438667013 in place barring any objections.

assigning to justincohen@. Please re-triage or close as necessary.

davidben@ any objections to leaving the iOS SIGPIPE mask as well?  Making as dup of 467132 since that's what https://codereview.chromium.org/2034433002/ will do

Yeah, I think it makes sense for Chrome/iOS to continue ignoring[*] SIGPIPE. SIGPIPE is dumb and you're a top-level application so there's no problem with changing dispositions.

[*] Confusingly, "ignoring" and "masking" are different. There's signal positions which are process-global and decide what to do when a signal is processed (ignore, crash process, run this function, etc.). Then there's per-thread signal masks which can defer a signal. When a signal is delivered to a whole process rather than a thread (not sure which it is for SIGPIPE), the kernel picks an arbitrary thread that doesn't have it masked off and uses that one.

> signal positions

signal dispositions