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