curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. 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 himself.

Re: libcurl read-llike interface.

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 15 Dec 2020 00:09:12 +0100 (CET)

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 might mean a larger and more complicated source code
to do it and it might mean adding more tests and complexity due to more code
paths and possibilities... which might lead to more bugs etc.

Optimizing is not a one dimension game. It's a balance.

That's why I emphasize that there needs to be a proven benefit to do something
like a zero-copy API for it to be worthwhile. Probably by doing a first
prototype implementation which can be used to run benchmarks.

> I mean any "significant" piece of code, not too short like examples in the
> official documentation and not too big (the size of fcurl is ideal) that
> uses "multi-socket" to get a taste and try to understand the subtle
> differences between multi-select and multi-socket!

I don't know. I don't keep any records of what libcurl-using applications use
what libcurl API.

The primary difference is that multi-socket is for event-driven traffic and
multi-select is for select() loops.

-- 
  / daniel.haxx.se
  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2020-12-15