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: Getting a list of easy handles in a multi handle - possible?
- 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, 28 Aug 2023 23:32:54 +0200 (CEST)
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.
Date: Mon, 28 Aug 2023 23:32:54 +0200 (CEST)
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.htmlReceived on 2023-08-28