Sorry Jiahao if I confused you! To summarise what was said in "previous episodes":
- a "read-like" interface was considered 4 years ago and a quick PoC (Proof of Concept) was made: fcurl (see https://github.com/curl/fcurl) - last commit April 2016. - there was a poll question last year about any interest for a "read-like" interface. But since this attempt didn't seem to have sparkled many interest so far, not speaking for the libcurl team, but I am not under the impression that this "new API" will be added anytime soon! I had already pointed to some possible limitations of this PoC, and to make it brief, I explain on my (too long) last post that doing a "decent" read-like interface would probably mean a lot of changes in how things work in the library. In the mean time, should you need the "read-like" interface (my case for a fuse driver), it is so trivial to do it from curl_easy_recv(), that this is a good starting point. Although this interface does not much, it is a great help to setup up the connection with added layers like proxies and TLS. It is and already an existing and supported interface. Out of curiosity, having read a bit about io_uring (just now), there is nothing new here! That was the base principle of a defunct O.S. (CTOS) I used at the beginning of my I.T. career. I just hope io_uring didn't forget "abort requests". :-) I can't clearly see how libcurl, and the use case it serves that are mostly "streams", could really leverage such a framework (apart from the underlying system calls that could use it). Cheers Alain ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
