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: Paul Fotheringham via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 28 Aug 2023 23:08:31 +0100
On Mon, 28 Aug 2023 at 22:32, Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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.
Thanks, much appreciated. I can see why in a general case that would
be something to be avoided.
In this case though the curl function invoking the callback is just a
loop over the easy handles with no other state to worry about. I
think?
To my mind you only need to consider two things to make it safe:
1. Make a copy of the handle list initially to ensure handles added by
the callbacks don't get a callback invoked on them.
2. After each callback finishes check that the next handle is still in
the multi's list to ensure we skip any handle removed by the
callbacks.
Testing would mainly focus on the addition/removal of handles during
the loop as that is the only state that is affected AFAICS.
If I'm way off the mark then sorry. If it's a general policy then
that's fine too, I completely understand.
Date: Mon, 28 Aug 2023 23:08:31 +0100
On Mon, 28 Aug 2023 at 22:32, Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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.
Thanks, much appreciated. I can see why in a general case that would
be something to be avoided.
In this case though the curl function invoking the callback is just a
loop over the easy handles with no other state to worry about. I
think?
To my mind you only need to consider two things to make it safe:
1. Make a copy of the handle list initially to ensure handles added by
the callbacks don't get a callback invoked on them.
2. After each callback finishes check that the next handle is still in
the multi's list to ensure we skip any handle removed by the
callbacks.
Testing would mainly focus on the addition/removal of handles during
the loop as that is the only state that is affected AFAICS.
If I'm way off the mark then sorry. If it's a general policy then
that's fine too, I completely understand.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-08-29