On Mon, 14 Dec 2020, XSLT2.0 via curl-library wrote:
But instructions you don't do are always faster than the one you do,
aren't they? This means efficiency, so less CPU for the same task.
It means less CPU for that particular copy, yes. But it might mean more CPU
for logic around it, it
> For a zero-copy API, I figure the application would somehow provide
the buffer first and then the callback would be done and tell the
application when (a piece of) the buffer has been populated.
Exactly!
You are right "zero-copy" or rather "caller provided buffers" won't
generally make things
On 14/12/2020 16:35, Daniel Stenberg via curl-library wrote:
> On Mon, 14 Dec 2020, XSLT2.0 via curl-library wrote:
>
>> It is also pretty un-optimised: the write callback could
>> be called multiple times in a multi_perform cycle.
>
> There's this saying about premature optimization...
You
On Mon, 14 Dec 2020, XSLT2.0 via curl-library wrote:
we don't get any feedback and nobody writes any pull requests for it.
The code is obviously incomplete, which helps a lot understanding things
because it is "short enough", but does probably not encourage to write PR?
That would explain
> https://github.com/curl/fcurl
Many thanks Daniel, that was extremely helpful for me to better
understand the "multi - select" way of doing thing.
> It has been untouched for years since nobody seems to use it,
> we don't get any feedback and nobody writes any pull requests for it.
The
On Sun, 13 Dec 2020, XSLT2.0 via curl-library wrote:
I saw on the 2020 poll an item about adding to libcurl a "read-like
interface" (instead of callbacks).
I didn't find any detail on that feature.
Well, it was a question in a poll about it. It doesn't have to mean that it
actually
Hello,
I saw on the 2020 poll an item about adding to libcurl a "read-like
interface" (instead of callbacks).
I didn't find any detail on that feature.
Would you have a link or some reading that could help me understand what
the benefits would be?
From the most obvious to the more beneficial,
