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
