On Mon, 27 Jan 2025, Malcolm Matalka via curl-library wrote:
Sorry to spam, but I think my understanding is not entirely correct. I believe this is a socket that curl (or the multi interface in particular?) is using for its own needs, and it's not necessarily part of a handle. The opensocket and closesocket callbacks are for a handle, which means they do not get called in this case.
The socketpair/eventfd file descriptors are not treated as sockets, they are mere file descriptors so they are not passed to CURLOPT_CLOSESOCKETFUNCTION.
The issue with my usage is that despite opensocket and closesocket not being called, the socketfunction callback is called to manage polling
Correct, since libcurl wants to be told when there's activity on the message pipe.
due to some constraints on my system, I cannot actually do the socketfunction callback work in the callback, but I think curl assumes it can, in which case it believes its safe to call close on the socket after the POLL_REMOVE.
Yes. libcurl tells the application about what sockets/file descriptors to monitor in the socket callback and when it has removed the descriptor from the set, it can close it.
The reason I can using CLOSESOCKET in a handle is because I need to be back in my program's control flow to do some cleanup before actually closing the socket.
It sounds like you want this for all file descriptors involved, not just the sockets. Which libcurl does not provide. Tricky.
Is my understanding correct? I understand this might be an unexpected usage of libcurl, but are there any suggested workarounds?
Not off the top of my head, no. -- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
