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: Network.framework and libcurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Thu, 28 Aug 2025 05:23:21 -0400
On 8/27/25 17:24, Daniel Stenberg wrote:
> On Wed, 27 Aug 2025, Demi Marie Obenour wrote:
>
>> I'm not surprised. Unless some of those callbacks need synchronous
>> processing, this could be handled by using AF_UNIX sockets to notify the
>> main thread. That said, I expect this behavior is for performance reasons,
>> as that is the documented reason for MsQuic to use callbacks on a thread
>> pool MsQuic owns.
>
> I think they chose that solution because it is easier. For them. msh3 turned
> out to be complicated to support partly because of its threads use.
Makes sense. I suspect msh3 is intended for bigger codebases that already have
thread pools and such under the hood, and for which this kind of stuff is no big
deal because everything is thread-safe already. libcurl doesn't work that way.
>>> We can't use name based API that does all this magic under the hood. Magic
>>> that curl needs to own and control itself.
>>
>> Unfortunately, any program that doesn’t do this will break if VPN On Demand
>> is in use. VPN On Demand startup is based on target domain name, not just
>> on IP address. This means that for a program to work correctly if VPN On
>> Demand is in use, using such an API is required.
>
> Given that not a single user has ever asked for that, it does not seem like a
> big problem for us.
Totally fair, though I would not be surprised if end-users have wondered why
XYZ app doesn't work with VPN On Demand with this being the root cause.
>> My recommendation would be to consider this a necessary workaround for a
>> platform quirk, and accept that this will result in differing behavior.
>
> As no user has asked for it and no developer has offered an implementation, I
> think we can simply defer the entire discussion.
I thought https://github.com/curl/curl/pull/17509 was that implementation
(and VPN On Demand was mentioned there), so I'm a bit confused.
>> I do question if requiring identical behavior on all platforms is worth
>> being broken (in a user-visible way) on Apple devices that have VPN On
>> Demand configured.
>
> We never actually achieve 100% "identical behavior" so that's not really what
> we require. You're still advocating for us to give up core principles "in
> theory" for a feature no one has asked for and no one has implemented.
>
> I prefer we have that discussion once we have both as then we have actual real
> code and real facts on the table. Then we know exactly what we talk about and
> what the decision is about.
I'll leave this discussion for later. I don't use macOS myself and don't
use VPN On Demand on iOS, which makes this purely a hypothetical for me.
Received on 2025-08-28
Date: Thu, 28 Aug 2025 05:23:21 -0400
On 8/27/25 17:24, Daniel Stenberg wrote:
> On Wed, 27 Aug 2025, Demi Marie Obenour wrote:
>
>> I'm not surprised. Unless some of those callbacks need synchronous
>> processing, this could be handled by using AF_UNIX sockets to notify the
>> main thread. That said, I expect this behavior is for performance reasons,
>> as that is the documented reason for MsQuic to use callbacks on a thread
>> pool MsQuic owns.
>
> I think they chose that solution because it is easier. For them. msh3 turned
> out to be complicated to support partly because of its threads use.
Makes sense. I suspect msh3 is intended for bigger codebases that already have
thread pools and such under the hood, and for which this kind of stuff is no big
deal because everything is thread-safe already. libcurl doesn't work that way.
>>> We can't use name based API that does all this magic under the hood. Magic
>>> that curl needs to own and control itself.
>>
>> Unfortunately, any program that doesn’t do this will break if VPN On Demand
>> is in use. VPN On Demand startup is based on target domain name, not just
>> on IP address. This means that for a program to work correctly if VPN On
>> Demand is in use, using such an API is required.
>
> Given that not a single user has ever asked for that, it does not seem like a
> big problem for us.
Totally fair, though I would not be surprised if end-users have wondered why
XYZ app doesn't work with VPN On Demand with this being the root cause.
>> My recommendation would be to consider this a necessary workaround for a
>> platform quirk, and accept that this will result in differing behavior.
>
> As no user has asked for it and no developer has offered an implementation, I
> think we can simply defer the entire discussion.
I thought https://github.com/curl/curl/pull/17509 was that implementation
(and VPN On Demand was mentioned there), so I'm a bit confused.
>> I do question if requiring identical behavior on all platforms is worth
>> being broken (in a user-visible way) on Apple devices that have VPN On
>> Demand configured.
>
> We never actually achieve 100% "identical behavior" so that's not really what
> we require. You're still advocating for us to give up core principles "in
> theory" for a feature no one has asked for and no one has implemented.
>
> I prefer we have that discussion once we have both as then we have actual real
> code and real facts on the table. Then we know exactly what we talk about and
> what the decision is about.
I'll leave this discussion for later. I don't use macOS myself and don't
use VPN On Demand on iOS, which makes this purely a hypothetical for me.
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature