My main issue with libcurl's multi interface is not that it is particularly complicated to use (admittedly, I had to spend some time to get it right but eventually it worked out). The bigger issue that I see is that the interface works async but it is not non-blocking. In order to keep track of what is going on, one has to repeatedly check whether a request already finished. That polling loop is an issue for applications with a graphical user interface because it blocks the UI-thread. At least that is the case if the UI shall be updated with information received from the request.
Many languages nowadays address this kind of problem by utilizing various implementations of resumable functions. That way, instead of polling the status of a request, the function just resumes when the request is done. Typically, the syntax of a language supporting this uses some form of "async"/"await" keywords (https://en.wikipedia.org/wiki/Async/await) to declare resumable functions. C# supports this (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/) and so do JavaScript (https://javascript.info/async-await), Python and some others. C++20 will also support resumable functions which are known there as "coroutines" (https://en.cppreference.com/w/cpp/language/coroutines). Once I get my hands on a C++ compiler supporting C++20 I intend to replace the usage of libcurl's multi interface in my application with coroutines that simply utilize libcurl's easy interface. This makes polling obsolete and my UI will never be blocked. Ideally, libcurl's async interface would follow the same approach and support a "async/await" kind of syntax. C does not have built-in support for resumable functions but there are probably library implementations available out there. I think this would not only remove the necessity to poll but also simplify the interface quite a bit. However, it would also mean that resumable functions would somehow need to be added to libcurl, either via (cross-platform!) library or directly as part of libcurl's codebase. -----Original Message----- From: curl-library [mailto:curl-library-boun...@cool.haxx.se] On Behalf Of Daniel Stenberg via curl-library Sent: Dienstag, 16. Juli 2019 12:08 To: libcurl hacking Cc: Daniel Stenberg Subject: Async thoughts Hi team, Recently I've talked to some users who, independently of each other, have brought up or touched the idea of (easier) async transfers with libcurl. The easy interface is fine and yeah, easy, but synchronous, and the multi interface is powerful and non-blocking and all but not always very easy to "just do async" with. Is there a way and a "need" for easier async with libcurl? If so, how should the API for this work? Is there an existing async API somewhere that's good or useful that we can learn from or be inspired by? If your dream async API came true, how would it work? The probably most basic way I can think of is firing off a separate thread with the "start transfer" call and then have have a way to probe how the transfer is going and finally a way to signal the completion of the transfer. Thoughts? -- / daniel.haxx.se | Get the best commercial curl support there is - from me | 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.haxx.se/mail/etiquette.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
