Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl_easy_recv and SIGPIPE
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 27 Oct 2020 00:54:43 +0100 (CET)
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?
Date: Tue, 27 Oct 2020 00:54:43 +0100 (CET)
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.htmlReceived on 2020-10-27