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: Close sockets asynchronously when using libdispatch (GCD)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 16 Jan 2023 10:24:15 -0800
On Mon, Jan 16, 2023 at 04:30:48PM +0100, Frederik Seiffert via curl-library wrote:
> When receiving CURL_POLL_REMOVE, I call dispatch_source_cancel() [2] to stop the dispatch source. As this is done asynchronously, it is required to wait for the cancellation handler before closing the socket according to the documentation:
>
> > The cancellation handler is submitted to the source's target queue when the source's event handler has finished, indicating that it is safe to close the source's handle (file descriptor or mach port).
>
> However libcurl closes the socket immediately after calling the socket function, and at least on Windows this causes GCD to sometimes crash because WSAEventSelect() returns WSAENOTSOCK ("Socket operation on nonsocket") here: [3].
>
> Does anyone have a suggestion as to how to work around this? The only thing I can think of is to use CURLOPT_CLOSESOCKETFUNCTION and wait for the cancellation handler before closing the socket. Would this be the recommended approach? I¢m fairly new to this topic, so I might be missing something obvious.
IMHO, that sounds like a good approach. curl assumes POSIX semantics on sockets
which allow them to be closed at any time. If your environment doesn't allow
that, then hooking in to CURLOPT_CLOSESOCKETFUNCTION sounds like a good way
to maintain those semantics.
> I found that building libcurl with "CURL_DISABLE_SOCKETPAIR" fixes most these crashes, but this seems like a poor workaround and some crashes remain.
I agree. That option just stops one source of socket closes, but others will
remain.
Dan
Date: Mon, 16 Jan 2023 10:24:15 -0800
On Mon, Jan 16, 2023 at 04:30:48PM +0100, Frederik Seiffert via curl-library wrote:
> When receiving CURL_POLL_REMOVE, I call dispatch_source_cancel() [2] to stop the dispatch source. As this is done asynchronously, it is required to wait for the cancellation handler before closing the socket according to the documentation:
>
> > The cancellation handler is submitted to the source's target queue when the source's event handler has finished, indicating that it is safe to close the source's handle (file descriptor or mach port).
>
> However libcurl closes the socket immediately after calling the socket function, and at least on Windows this causes GCD to sometimes crash because WSAEventSelect() returns WSAENOTSOCK ("Socket operation on nonsocket") here: [3].
>
> Does anyone have a suggestion as to how to work around this? The only thing I can think of is to use CURLOPT_CLOSESOCKETFUNCTION and wait for the cancellation handler before closing the socket. Would this be the recommended approach? I¢m fairly new to this topic, so I might be missing something obvious.
IMHO, that sounds like a good approach. curl assumes POSIX semantics on sockets
which allow them to be closed at any time. If your environment doesn't allow
that, then hooking in to CURLOPT_CLOSESOCKETFUNCTION sounds like a good way
to maintain those semantics.
> I found that building libcurl with "CURL_DISABLE_SOCKETPAIR" fixes most these crashes, but this seems like a poor workaround and some crashes remain.
I agree. That option just stops one source of socket closes, but others will
remain.
Dan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-16