Re: Getting a list of easy handles in a multi handle - possible?

From: bch via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 28 Aug 2023 15:02:53 -0700

On Mon, Aug 28, 2023 at 14:59 bch <brad.harder_at_gmail.com> wrote:

>
>
> 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.
>

Though then the resultant list is subject to some staleness, etc as
previous discussion… perhaps not as interesting as I initially hoped.



> -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.html

Received on 2023-08-29