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: Malcolm Matalka via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 27 Jan 2025 23:55:21 +0100
Daniel Stenberg <daniel_at_haxx.se> writes:
> 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.
Yes exactly. I'm not sure of the design evolution it took to get to the creation of the OPENSOCKET and CLOSESOCKET callback functions, but is there is similar argument that could be made here to motivate providing that flexibility to all of the sockets? I'm imagining similar set of callbacks for the multi handle.
>
>> 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:55:21 +0100
Daniel Stenberg <daniel_at_haxx.se> writes:
> 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.
Yes exactly. I'm not sure of the design evolution it took to get to the creation of the OPENSOCKET and CLOSESOCKET callback functions, but is there is similar argument that could be made here to motivate providing that flexibility to all of the sockets? I'm imagining similar set of callbacks for the multi handle.
>
>> 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.
-- Malcolm Matalka Terrateam -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-28