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

From: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 26 Oct 2020 23:56:27 +0000

On 26/10/2020 23:54, Daniel Stenberg wrote:
> 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?
>
I'm just telling you what I've seen Daniel.

Have a good one.

Cheers

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27