> 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.
Yes, I initially wanted to use the approach that stores the array of "waitids" internally, but decided to propose the "client provides the buffer" approach because it will make things much simpler, and for clients interesting in this function, it is not difficult to implement the mechanism with minimum of reallocations with a full control of how memory is used. > 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. The curl_multi_poll() is a very good API, but it is not always possible to use it in cases when there is already existing "poll" framework, which cannot be easily changed internally (i.e. 3rd party code). In such cases, ability to extract "poll ids" from curl and pass it to the polling framework is probably the only solution. Also, I was facing cases in my application (which kind of a very large framework that may run independent "plugins" using libcurl) where in some cases it needs to run multiple independent multi-transfers in parallel in a single thread. I was hoping to use the curl_multi_poll() for such case, using the first multi-handle as a "driver", and the rest multi-transfers as "extra ids", but I couldn't extract "poll ids" from the multi-transfers. This was another reason why I came up with the idea of curl_multi_pollfds(), which seems like a natural addition to the curl_multi_fdset(), which provides a similar functionality for external "select" frameworks. > The CURLMOPT_SOCKETFUNCTION callback solves that already. The callback approach unfortunately is not easy to use (or not even possible) when a code driving multi-transfers is deeply separated from the code setting multi-transfers, which may use the callbacks for their own purposes. Thanks, Dmitry Karpov -----Original Message----- From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Daniel Stenberg via curl-library Sent: Monday, December 18, 2023 9:10 AM To: Timothe Litt via curl-library <curl-library@lists.haxx.se> Cc: Daniel Stenberg <dan...@haxx.se> Subject: [EXTERNAL] Re: Question/proposal about function returning pollfds from multi handle 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.html
