Buy commercial curl support from WolfSSL. 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
himself.
Re: Question/proposal about function returning pollfds from multi handle
- 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, 18 Dec 2023 18:10:17 +0100 (CET)
On Mon, 18 Dec 2023, Timothe Litt via curl-library wrote:
> Is there a thread safety issue with this? E.g. one thread calls, buffer
> changes due to allocating more FDs in second thread, first thread now has
> cached pointer to freed memory (use after free).
The handle can only be used in a single thread, so this is safe.
> In any case, the traditional way for the user to get the buffer size
> required is to return the needed size with a non-fatal error code.
That's exactly what Dmitry proposed. But then the applications need to do that
realloc-dance instead, and it has to do it for every time this function is
used. I figured my take could be a little more convenient and perhaps
effective. I'm not married to that way.
I'm not even sure this new proposed function is actually necessary. We have
curl_multi_poll() already which should be a slicker API for most users I
believe.
> This also raises the question of how the caller knows that it's necessary to
> get an updated list of active fds.
Yes, which also speaks in favor of curl_multi_poll(). It needs to update the
list again as soon as a multi function has been used.
> Another approach would be for libcurl to register a callback triggered when
> an fd is opened/closed, and provide the user with a curl_waitfd & open/close
> flag.
The CURLMOPT_SOCKETFUNCTION callback solves that already.
Date: Mon, 18 Dec 2023 18:10:17 +0100 (CET)
On Mon, 18 Dec 2023, Timothe Litt via curl-library wrote:
> Is there a thread safety issue with this? E.g. one thread calls, buffer
> changes due to allocating more FDs in second thread, first thread now has
> cached pointer to freed memory (use after free).
The handle can only be used in a single thread, so this is safe.
> In any case, the traditional way for the user to get the buffer size
> required is to return the needed size with a non-fatal error code.
That's exactly what Dmitry proposed. But then the applications need to do that
realloc-dance instead, and it has to do it for every time this function is
used. I figured my take could be a little more convenient and perhaps
effective. I'm not married to that way.
I'm not even sure this new proposed function is actually necessary. We have
curl_multi_poll() already which should be a slicker API for most users I
believe.
> This also raises the question of how the caller knows that it's necessary to
> get an updated list of active fds.
Yes, which also speaks in favor of curl_multi_poll(). It needs to update the
list again as soon as a multi function has been used.
> Another approach would be for libcurl to register a callback triggered when
> an fd is opened/closed, and provide the user with a curl_waitfd & open/close
> flag.
The CURLMOPT_SOCKETFUNCTION callback solves that already.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-12-18