Buy commercial curl support. 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 Daniel himself.
Re: What's the nature of curl_multi_socket_all's deprecation?
- 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: Wed, 13 Nov 2024 14:24:13 +0100 (CET)
On Tue, 12 Nov 2024, Jacob Champion via curl-library wrote:
> Is curl_multi_socket_all() deprecated because
>
> a. it's pointlessly inefficient for the vast majority of applications,
> b. it's subtly bugged in a way that can cause transfer failures,
> c. the project would prefer to remove it at some point in the future, or
> d. some combination of the above?
>
> From the notes on commit 76627b322, and the associated thread [1], I
> assume the answer is (a), but I wanted to ask and make sure.
I would say A + a little of C, but the C part has over the years become a
realization that it might just never actually happen.
> Ignoring deprecation warnings raises my blood pressure, but it really does
> look like exactly the API I need, and I will happily trade efficiency for
> lower complexity here -- as long as it's not actually broken. Am I about to
> cause myself a bunch of pain?
In reality, no. There is no plan to actually ever remove this as there is no
plan to ever break the ABI like that. Ten, fifteen years ago I had a different
view and expectation on that would play out.
The deprecation notice should probably mostly be read as "this function has
bad performance properties and is not the recommended API to use unless you
reall really can't avoid it".
Date: Wed, 13 Nov 2024 14:24:13 +0100 (CET)
On Tue, 12 Nov 2024, Jacob Champion via curl-library wrote:
> Is curl_multi_socket_all() deprecated because
>
> a. it's pointlessly inefficient for the vast majority of applications,
> b. it's subtly bugged in a way that can cause transfer failures,
> c. the project would prefer to remove it at some point in the future, or
> d. some combination of the above?
>
> From the notes on commit 76627b322, and the associated thread [1], I
> assume the answer is (a), but I wanted to ask and make sure.
I would say A + a little of C, but the C part has over the years become a
realization that it might just never actually happen.
> Ignoring deprecation warnings raises my blood pressure, but it really does
> look like exactly the API I need, and I will happily trade efficiency for
> lower complexity here -- as long as it's not actually broken. Am I about to
> cause myself a bunch of pain?
In reality, no. There is no plan to actually ever remove this as there is no
plan to ever break the ABI like that. Ten, fifteen years ago I had a different
view and expectation on that would play out.
The deprecation notice should probably mostly be read as "this function has
bad performance properties and is not the recommended API to use unless you
reall really can't avoid it".
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-11-13