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.html
