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: bch via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 28 Aug 2023 14:59:03 -0700
On Mon, Aug 28, 2023 at 14:32 Daniel Stenberg via curl-library <
curl-library_at_lists.haxx.se> wrote:
> 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.
>
That all makes sense -
What I was thinking of as the strength of my original proposal is
up-to-the-moment canonical truth (because calls are dispatched from within
curl itself with its own known state); it might be starting to get clunky
(food for discussion) - but perhaps the contract
1) whitelists known-good functions, or
2) CURLM* and CURL* handles are for reading purposes only, and subsequent
ops are relegated to (eg) querying the callers own userdata upon return of
curlm_easy_iter() and operating in “typical scope” rather than some
arbitrary callback depth.
-bch
> --
>
> / 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
>
Date: Mon, 28 Aug 2023 14:59:03 -0700
On Mon, Aug 28, 2023 at 14:32 Daniel Stenberg via curl-library <
curl-library_at_lists.haxx.se> wrote:
> 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.
>
That all makes sense -
What I was thinking of as the strength of my original proposal is
up-to-the-moment canonical truth (because calls are dispatched from within
curl itself with its own known state); it might be starting to get clunky
(food for discussion) - but perhaps the contract
1) whitelists known-good functions, or
2) CURLM* and CURL* handles are for reading purposes only, and subsequent
ops are relegated to (eg) querying the callers own userdata upon return of
curlm_easy_iter() and operating in “typical scope” rather than some
arbitrary callback depth.
-bch
> --
>
> / 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
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-08-28