On 26/10/2020 22:09, Daniel Stenberg wrote: > On Mon, 26 Oct 2020, Tomalak Geret'kal via curl-library > wrote: > >> On closer examination, sigpipe_ignore is a no-op unless >> USE_OPENSSL or USE_MBEDTLS are set. > > Are you saying you're not using any of them? > >> So it seems the call in curl_easy_perform is only really >> intended to eat up pipes raised by either of those >> libraries, thus perhaps they don't really make sense on a >> "raw" byte-reading function. > > Those are the only places that can trigger SIGPIPE, me > knowingly! All uses of the sockets by libcurl itself > should already be protected. > I got it from curl_easy_recv. I believe the triggering condition was iOS nuking the underlying socket while the app was suspended.
Based on the `#if defined`s in sigpipe.h, from what I can tell, curl doesn't protect anything from SIGPIPE unless OpenSSL or MBEDTLS are in use. I don't know whether your intention was to protect against SIGPIPE more broadly or not. Admittedly my build is using a "non-standard" config-ios.h, but the result is USE_SECTRANSP which I believe is supported and also available for use by Mac builds. Unless I'm missing something, this condition would also cause a SIGPIPE on a Mac, for example... though I'm not sure how you'd ever trigger it on that particular platform. N.B. after I just chucked a "signal(SIGPIPE, SIG_IGN)" call at the top of my program and called it a day, I found that "dead" socketry also impacted the wakeup socket pair as managed by curl_multi_poll - see issue #6132 for more on that. :) Cheers ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
