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.
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: Jacob Champion via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 12 Nov 2024 12:29:22 -0800
Hi all,
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.
= Why does it matter? =
I've convinced myself that I have a valid use case for it.
Gory details: I'm working on a HTTP feature for libpq [2], which is
itself a library that doesn't have any control over the event engine
in use. Its clients don't know libcurl exists underneath its API, and
for backwards compatibility reasons, I have exactly one file
descriptor per "connection handle" with which I can communicate with
the top-level application and whatever engine it's decided to use.
I can work with those constraints. Several platforms let me multiplex
the sockets and timeouts that a multi handle gives me into a single
file descriptor (epollset, kqueue, etc.). That works great, but the
application has no idea which socket or timeout caused its handle to
wake up, so it can't give me the data I need to call
curl_multi_socket_action().
So either 1) I need to write code that meticulously walks over the
multiplexed descriptors to figure out which of them has woken up, or
2) I can use an API that is documented to do exactly that and will
presumably continue to do so into the future: curl_multi_socket_all().
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?
Thanks!
--Jacob
[1] https://curl.se/mail/lib-2007-04/0101.html
[2] https://www.postgresql.org/message-id/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel%40vmware.com
Date: Tue, 12 Nov 2024 12:29:22 -0800
Hi all,
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.
= Why does it matter? =
I've convinced myself that I have a valid use case for it.
Gory details: I'm working on a HTTP feature for libpq [2], which is
itself a library that doesn't have any control over the event engine
in use. Its clients don't know libcurl exists underneath its API, and
for backwards compatibility reasons, I have exactly one file
descriptor per "connection handle" with which I can communicate with
the top-level application and whatever engine it's decided to use.
I can work with those constraints. Several platforms let me multiplex
the sockets and timeouts that a multi handle gives me into a single
file descriptor (epollset, kqueue, etc.). That works great, but the
application has no idea which socket or timeout caused its handle to
wake up, so it can't give me the data I need to call
curl_multi_socket_action().
So either 1) I need to write code that meticulously walks over the
multiplexed descriptors to figure out which of them has woken up, or
2) I can use an API that is documented to do exactly that and will
presumably continue to do so into the future: curl_multi_socket_all().
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?
Thanks!
--Jacob
[1] https://curl.se/mail/lib-2007-04/0101.html
[2] https://www.postgresql.org/message-id/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel%40vmware.com
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-11-12