On Mon, 28 Aug 2023, Paul Fotheringham wrote:
That thread seemed to peter out without a reply to Brad's question. I too would benefit from an example of why calling libcurl functions from within the callback is tricky to handle. I'm not saying it's not tricky to handle, I just ask from a position of ignorance.
First out, we already deny most libcurl functions from getting called from their callbacks precisely because of the challenges.
When libcurl calls a callback it is "in the middle of something", while when it returns back to the caller, it has finished doing it and stores the state correctly somewhere in order to be able to continue from there at the next invokation.
When a callback calls libcurl *back* in a recursive manner, it is hard to make sure that alls states, pointers and variables are handled correctly. Since the recursively called function changes internals and then returns back to the callback that returns back into libcurl again ... into another context which may have local state or variables that now no longer actually are correct because things have been changed.
It is of course quite *possible* to make this work (it is just code after all) but it requires deliberate attention to this and quite a lot of testing to make sure lots of edge cases are covered. And we don't do nor have that. As I said: we prevent the recursive call instead to protect the application from problems.
By avoiding recursive calls into the library our lives are much easier. -- / 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
