On Mon, 26 Oct 2020, Tomalak Geret'kal via curl-library wrote:
I don't think so, since it uses callbacks to our code for the actual
sending to the socket and we set the socket to not cause sigpipes. At least
that's the intention.
That only helps you if the socket still exists.
The socket still exists, it's only the connection that is gone. If the socket
didn't exist, there would not be any SIGPIPE at all it would be a system call
using a bad file descriptor and a subsequent crash.
On wake from suspend on iPad, the socket does not exist any more, an event
is raised on its FD, then you get a failed recv (with a SIGPIPE unless it's
been externally SIG_IGNored), with errno ENOTCONN.
If SO_NOSIGPIPE was set on the file descriptor, there should be no SIGPIPE and
no reason to ignore any (on a mac at least).
There exists no protection in libcurl for error cases like this
... because SO_NOSIGPIPE doesn't work on iOS? What protection do you say
libcurl lacks?
the only question is, do you want there to be!
As I've explained several times now: we already attempt to avoid SIGPIPEs so
clearly we want that.
The question is still: why do you get a SIGPIPE?
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
