True and duly noted Daniel! Fortunately http/1.1 is simple enough, especially when downloading the "body" of a file (with Connection: close), you must admit that redoing what libcurl does here amounts to nothing.
I am even glad with avoiding a "full relay copy" (every bit of efficiency helps when writing a "filesystem") and with EAGAIN: it perfectly fits the use case (parallel out of order reads)! Since being able to get a good working "read-like" interface is an extreme simplification and performance boost for my program, it is the solution I have chosen to explore. As you write yourself: it is a question of balance! IMHO, the biggest issue with read-like on top of libcurl's current callbacks (fcurl) is "excess bytes" that are pulled out of the socket. Pardon me if I am a bit abrasive here, but wouldn't the same remark apply: why should a user library manage those "excess bytes" that are natively taken care of by the kernel in socket functions (recv/read)? I'll change it back to using the whole of libcurl if/when it becomes possible to get a "decent" read-like other than using curl_easy_recv(), which I doubt will be an easy task considering the current architecture of libcurl. Also as demonstrated by the lack of interest about fcurl, writing a fuse driver (filesystem) might be one of those extremely rare occasions where a good working read-like interface makes a huge difference: efficiency + simpler code. So I understand libcurl has other much higher priorities than doing it, and unfortunately I don't feel "libcurl-skilled" enough myself to propose a (huge) PR + new API for that matter. Subsidiary question, I have noted that changing the socket to "blocking" (with fcntl) seems to work perfectly, at least for http/1.1 GET. I don't really need it (quite the opposite), but was just testing performance: it does not seem to help either! Would such a change be a problem in other uses of curl_easy_recv()? Cheers Alain > We discourage users from using curl_easy_recv() for doing any protocol > that libcurl implements natively. Mostly because you need to pretty > much re-implement everything yourself instead of letting libcurl do > what it was designed to do. > ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
