Re: CLOSESOCKETFUNCTION not always called in multi

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