Buy commercial curl support. 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 Daniel himself.
Re: CLOSESOCKETFUNCTION not always called in multi
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 27 Jan 2025 23:08:25 +0100 (CET)
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.
Date: Mon, 27 Jan 2025 23:08:25 +0100 (CET)
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.htmlReceived on 2025-01-27